The claims-based identity is an identity model in SharePoint Foundation and Microsoft 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

Note
For more information about signing into SharePoint and the different sign-in modes, see Incoming Claims: Signing into SharePoint.

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.

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

Forms-based authentication provides custom identity management in SharePoint Foundation by implementing a membership provider, which defines interfaces for identifying and authenticating individual users, and a role manager, which defines interfaces for grouping individual users into logical groups or roles. In SharePoint Foundation, a 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 security token service (STS). The STS creates the user 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.

Note
For more information about STS, see Claims-Based Identity Overview and Concepts.

The role manager is optional. If a custom authentication system does not support groups, a role manager is not necessary. SharePoint Foundation supports one membership provider and one role manager per URL zone (SPUrlZone). The ASP.NET forms roles have no inherent rights associated with them. Instead, SharePoint Foundation assigns rights to the forms roles through its policies and authorization. In SharePoint Foundation, the forms-based authentication is integrated with the claims-based identity model. If you need additional augmentation to bypass the limit of having one role provider per URL Zone, you can rely on claims providers.

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

In ASP.NET membership and role passive sign-in, the sign-in happens by redirecting the client to a Web page where the ASP.NET log-in controls are hosted. After the identity object that represents a user identity is created, SharePoint Foundation 2010 converts it to a ClaimsIdentity object (which represents a claims-based representation of a user).

Note
For more information about signing into SharePoint, see Incoming Claims: Signing into SharePoint.

SharePoint Foundation consumes the standard ASP.NET 2.0 role provider interface to gather group information about the current user. For authentication purposes, roles and groups are the same thing: a way of grouping users into logical sets for authorization. Each ASP.NET role is treated as a domain group by SharePoint Foundation.

For information about the pluggable authentication framework provided by ASP.NET, see New Security Features in ASP.NET 2.0.

Note
For more information about forms-based authentication, see Forms Authentication in SharePoint Products and Technologies (Part 1): Introduction.

Concepts