Why Use Claims-Based Identity
Applies to: SharePoint Foundation 2010
The claims-based identity is an identity model in Microsoft SharePoint Foundation 2010 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.
Disparate Authentication Systems
Most enterprise applications need some basic user security features. At a minimum, they need to authenticate their users, and many also need to authorize access to certain features so that only users with specific privileges can access them. Sometimes these authorization rules require attributes not found in existing user security tokens; for example, a distribution list from Microsoft Exchange Server can be used as a principal to secure some objects in SharePoint Server 2010. These security features are built into the Windows operating system, and are usually easy to integrate into an application. By taking advantage of Integrated Windows authentication, you do not have to create your own authentication protocol or manage a user database. By using access control lists (ACLs), impersonation, and features such as groups, you can implement authorization without writing much code.
Similar to Windows, SharePoint Foundation 2010 and SharePoint Server 2010 offer a set of features to facilitate authorization tasks, and for some objects (such as the Site object) this occurs behind the scenes automatically. This guideline applies regardless of which operating system or application you are using. It is almost always better to integrate closely with the built-in SharePoint security features than to reinvent those features yourself.
But, what happens when you want to reach users who do not have Windows accounts? What about users who are not running Windows at all? More and more applications need this type of access to these types of users, which seems to be the opposite of traditional security requirements. Claims-based identity is the new identity model in SharePoint Foundation 2010 and SharePoint Server 2010, designed to help address these and other problems.
On Windows, the most common type of credential used to access an enterprise application is the user's domain account. An application that uses Integrated Windows authentication receives a Kerberos ticket to represent a client. An application using Secure Sockets Layer (SSL) might instead receive an X.509 certificate for the client. A Kerberos ticket and an X.509 certificate are very different items, and the code in the operating system that parses, validates, and ultimately presents the data inside is also very different. But, if you think about what they really represent, you see that these two credentials have a lot in common.
Imagine the following scenario. Alice is a user who wants to access a purchasing service by using her Windows domain account. Her domain controller authenticates her, and creates a Kerberos ticket with a set of security identifiers (SIDs) in it. These SIDs represent Alice's user account and the domain groups in which she is a member. The SIDs are embedded in the ticket with a signature from the domain controller. In terms of identity, an "issuer" (the domain controller) gives a subject (Alice) a security token that she can use to prove her identity.These same ideas apply when Alice uses a certificate instead. A certificate is just another type of security token. In this case, the issuer is a certificate authority (CA) and the subject is Alice. Both the Kerberos ticket and the certificate are, in essence, signed statements by an issuer about a subject. These are two different ways that a trusted authority can vouch for one of its subjects. Each signed statement can be thought of as a collection of claims. Said differently: The domain controller is making claims about Alice's identity when it signs the list of SIDs in her ticket. Each SID becomes a claim. The certificate authority makes claims about Alice's identity when it signs her name and public key. The name and public key are examples of claims in the certificate.
The goal of this new identity model is to abstract identity in a way that reduces your dependency on specific types of credentials, without compromising the security of your application. By coding to the identity model in SharePoint Server 2010, you can process the delegate user's identity without Kerberos tickets and also process Security Assertion Markup Language (SAML) tokens. This opens the door to some interesting identity architectures, including federated identity.
See Also
Concepts
Getting Started with Security and Claims-Based Identity Model