What's New: Security Enhancements

Applies to: SharePoint Foundation 2010

Microsoft SharePoint Foundation and Microsoft SharePoint Server 2010 continue to build on and enhance the security features in Windows SharePoint Services 3.0 and Microsoft Office SharePoint Server 2007. This topic summarizes the new features and enhancements for security in SharePoint Foundation and SharePoint Server 2010.

Claims-Based Identity and Authentication

Claims-based identity is an identity model in SharePoint Foundation and SharePoint Server 2010 that includes features such as authentication across users of Windows-based systems and systems that are not Windows-based, multiple authentication types, stronger real-time authentication, a wider set of principal types, and delegation of user identity between applications.

When a user signs in to SharePoint Foundation and SharePoint Server 2010, the user's token is validated and then used to sign in to SharePoint. The user's token is a security token issued by a claims provider. There are five supported sign-in or access modes in SharePoint Foundation and SharePoint Server 2010:

• Windows Classic–Mode Sign-In

• Windows Claims–Mode Sign-In

• SAML Passive Sign-in Mode

• ASP.NET Membership and Role Passive Sign-In

• Anonymous Access

When you build claims-aware applications, the user presents an identity to your application as a set of claims. One claim could be the user’s name, another might be an e-mail address. The idea here is that an external identity system is configured to give your application all the information that it needs about the user with each request, along with cryptographic assurance that the identity data received by your application comes from a trusted source.

Under this model, single sign-on is much easier to achieve, and your application is no longer responsible for the following:

• Authenticating users

• Storing user accounts and passwords

• Calling to enterprise directories to look up user identity details

• Integrating with identity systems from other platforms or companies

Under this model, your application makes identity-related decisions based on claims supplied by the user. This could be anything from simple application personalization with the user’s first name, to authorizing the user to access higher-value features and resources in your application.

For more information about claims-based identity and claims providers, see Claims-Based Identity Overview and Concepts and Claims Provider.

ASP.NET Membership User Token Converted to Claims Security Token

In SharePoint Foundation, an ASP.NET membership provider must implement the required System.Web.Security.Membership.ValidateUser method. Given a user name, the role provider system returns a list of roles to which the user belongs. The membership provider is responsible for validating the credential information by using the System.Web.Security.Membership.ValidateUser method (required now in SharePoint Foundation).

However, the actual user token is created by the SharePoint Foundation security token service (STS). The SharePoint Foundation STS creates the claims security token from the user name validated by the membership provider, and from the set of group memberships associated with the user name that are provided by the membership provider.

Automatic Password Change and Managed Accounts

The new automatic password change feature in SharePoint Foundation enables you to update and deploy passwords without having to perform manual password update tasks across multiple accounts, services, and Web applications. This makes managing password in SharePoint Foundation simpler. You can use the automatic password change feature to determine whether a password is about to expire and to reset the password by using a long, cryptographically-strong random string.

You use managed accounts to implement the automatic password change feature. Managed accounts in SharePoint Foundation improves security and ensures application isolation.

For more information about the managed account API, see:

• SPManagedAccount

• SPManagedAccount.EventProcessingOptions

• SPManagedAccount.EventType

Effective Permission API

In Windows SharePoint Services 3.0, it is difficult to get a user’s effective permission on securable objects, such as SPWeb, SPList, SPListItem, and so on. Over time, the site can have very complex permission settings, especially when many objects do not inherit permissions from the parents (unique scope). It is difficult for administrators to determine the effective permission of a specific user and how the user gets the permission on a particular object. SharePoint Foundation introduced a new ribbon command named Check Permissions and a set of effective permission APIs that provide a quick way to enumerate all role assignments for a specific user in a specific scope.

The SPSecurableObject class exposes a new GetUserEffectivePermissionsInfo() method. This method retrieves an object with detailed information about the effective permissions that a specified user has in the current scope and the role assignments related to this user at this scope. This method does not include Web application security policy information in the permission mask if the provided user belongs to a policy that is marked as "Account Operate as System".This method is available for users who have the EnumeratePermissions permission granted. For more information about EnumeratePermissions, see the SPBasePermissions enumeration.

The SPSecurableObject class also exposes a new GetUserEffectivePermissions() method. For the current scope, this method returns a SPBasePermissions object that represents the effective permission mask of the user.

The SPWeb class has a new method named GetWebsAndListsWithUniquePermissions() for site collection administrators to retrieve a collection of Webs and lists that have unique permissions themselves or that have items with unique permissions.

The behavior of the API is as follows: From the starting URL, it returns a list of URLs of containers (for example, SPWeb or SPList) where a unique security scope is present (where Break Roles Inheritance occurred), including all containers that do not have a unique security scope but that contain one or many child items with unique security scopes.

The SPList class has a new GetItemsWithUniquePermissions() method for site collection administrators to retrieve all list items with unique permissions.

For more information about these APIs , see Microsoft.SharePoint.

Secure Store Service

The Secure Store Service replaces the Microsoft Office SharePoint Server 2007 Single Sign On feature. Secure Store Service is a service that provides storage and mapping of credentials such as account names and passwords. It enables you to securely store data that provides credentials that are required for connecting to external systems and for associating those credentials to a specific identity or group of identities. It is common for solutions to try to authenticate to an external system in which the current user is known differently or has a different account for authentication. In such cases, Secure Store Service can be used to store and map user credentials that are required by the external system. You can configure Secure Store Service so that multiple users can access an external system by using a single set of credentials on that external system.

For more information about Secure Store Service, see Secure Store Service.

See Also

Concepts

Getting Started with Security and Claims-Based Identity Model