Understanding Claims Based Authentication in SharePoint 2010

Many IT pros will experience claims-based authentication first with SharePoint 2010; others have already experienced it with Active Directory Federated Services (ADFS), and yet others will work with it in Azure, but there's no doubt that in the coming years, claims authentication will be important in the identity management space.

Claims-based authentication is just a standards-based, extensible implementation of concepts you already understand as an IT pro. This article focuses on the implementation of claim-based authentication in  SharePoint 2010, but the conceptual foundation will help you with other claims-authentication products, including ADFS 2.0. Let's look at what claims authentication is and then how you use it in SharePoint.

Review Windows Authentication

Claims-based authentication is a flexible framework based on Security Assertion Markup Language (SAML) tokens and built on the Windows Identity Foundation (WIF). Tokens contain assertions about a user's identity that are generated by trusted authentication providers, which include Windows authentication—just as in classic-mode authentication—as well as forms-based authentication (FBA), and standard SAML tokens issued by trusted authorities such as Windows Live ID or ADFS 2.0.

By extending the reach of trusted authentication providers, claims-based authentication enables authentication across Windows-based systems and non-Windows based systems. claims-based authentication becomes particularly powerful when tokens contain other user attributes, such as demographic or organizational information. These attributes can originate within the user's organization, other organizations, or the Internet. If you're not familiar with claims-based authentication, that description might sound complex. But it doesn't need to be.The concepts related to claims-based authentication are straightforward if you start from the perspective of an authentication scheme that you already understand: authentication within a Windows domain. Let's review the basics of Windows authentication as a basis from which to understand claims-based authentication.

When you require access to a system, for example a file server, the system must know who you are before it grants you access to resources. It would not be manageable to maintain a list of user names and passwords on each system. Therefore, you create a Windows domain by implementing Active Directory Domain Services (AD DS). Within a domain, all systems trust the authentication mechanism of the domain—Kerberos services running on the DCs—to validate the identity of a user. So when you access a file server, the file server does not have to authenticate you. Instead, you bring to the server a Kerberos service ticket that identifies you. The ticket has been created using processes that include encryption using keys known only by the server and the domain. So the server knows that the service ticket is valid. It looks at the ticket to know who you are. The server accepts the ticket's assertion about your identity because the server trusts the source of the ticket—the AD DS domain's Kerberos Key Distribution Center (KDC). Because the server trusts an external authentication provider, it doesn't need to perform authentication.

The Kerberos service ticket also contains a list of your domain security group memberships. Again, because the ticket comes from a trusted authority, the server uses that list of groups. The server builds a token that contains your identity—your user account's SID—and the SIDs of the groups to which you belong. The local security subsystem uses the token to determine whether you have access to a file by comparing the SIDs on the file's ACL with the SIDs in your token. This security token represents you to the local server.

In the past, when a developer wanted to create a secure website, the developer had to build an authentication component. With SharePoint, in classic-mode authentication, your Windows security token is translated into an object that represents you within SharePoint. The object is called an SPUser object. You can think of the SPUser object in a SharePoint web application as the conceptual equivalent of your Windows security token. It represents you during your interactions with the web application.

Claims Authentication

A claim is a set of assertions (i.e., information about a user). At the most basic conceptual level, a Kerberos service ticket is a claim that, among other things, asserts a user's identity and group memberships. When you access a SharePoint web application that uses claims-based authentication, the web application accepts a claim and translates that claim into the SPUser object, which represents you during your interactions with the Web application.

This is the first difference between classic-mode authentication and claims-based authentication. In classic-mode authentication, the web application relies on Microsoft IIS to pass your Windows security token to the web application. In claims-based authentication, the web application relies on the farm's Security Token Service (STS) to deliver a token that contains claims, including claims about your identity. The STS a service application that is required, is created automatically when you create a farm, and should never be removed. Its purpose is to create claims tokens.

In classic-mode authentication, IIS relies on AD to perform authentication. IIS can receive credentials via several methods (e.g., NTLM, Kerberos, Basic, Digest). In the case of NTLM, Basic, and Digest authentication, IIS authenticates the credentials against AD. In the case of Kerberos authentication, the service ticket contains credentials that have already been authenticated.

In claims-based authentication, as Figure 1 shows, the STS does not actually perform authentication. Instead, it relies on a trusted authority to do so, in the UI. This authority is called the authentication provider. The authentication provider can be Windows (AD) or one of several other providers. If the claims-based application uses the Windows authentication provider, the STS performs essentially the same function as IIS does in classic-mode authentication. If Kerberos is available, the service ticket is processed and turned into a set of claims about the user's identity and group memberships. If NTLM, Basic, or Digest authentication are used, the user's credentials are authenticated by AD, and the NTToken is translated into a set of claims about the user's identity and group memberships. The resulting claims are provided to the web application as a token, which is translated into an SPUser object within the web application.

By this point in the discussion, you should understand that there's a component called an STS that's doing the work of building tokens that contain claims. The STS's role in creating tokens for SharePoint is conceptually equivalent to the KDCs role in issuing Kerberos tickets on your Windows DC. You should also understand that if you use only Windows authentication, there's conceptually little difference between classic-mode authentication and claims-based authentication. But the story is just beginning.

What if you want to make a web application available to partners, but you don't want to add accounts for partner users to your AD DS domain? Before .NET authentication providers were introduced, a web developer would have to write a custom component to authenticate users and to administer user identities. Now, however, you can use the Forms Based authentication (FBA) provider to authenticate users against credentials stored in AD DS, in Active Directory Lightweight Directory Services (AD LDS), in a database such as a Microsoft SQL Server database, or in an LDAP data store such as Novell eDirectory, Novell Directory Services (NDS), or Sun ONE. Or you can use SAML to authenticate users based on credentials stored in a token provided by ADFS 2.0, by Windows Live ID, or by a custom trusted source.

Claims-based authentication thus allows SharePoint web applications to be extended to more diverse sets of users, across domains, forests, and non-Windows environments. You can change the authentication provider or the methods of authentication without having to change the web application itself, as long as the web application accepts and understands claims!

Trust

How are claims actually built? When you attempt to access a web application that uses claims-based authentication, you're transparently redirected to a sign-in page for the STS, by which you're authenticated. In some cases, such as Windows authentication, you might never even see this transaction if you configure your browser's security settings to authenticate you silently to trusted sites, and if the website is in a trusted zone. In other cases, such as FBA, you'll see a visible page on which to enter your username and password. The STS authenticates you and provides a token to your browser. Your browser then returns to the original website, submits the token, and the web application then knows who you are.

The process uses a series of standards called WS-* standards, which effectively ensure that the token can be used by the web application. To make a long, complicated story short, the web application has been configured to trust the STS. The trust involves the exchange of certificates that are used to encrypt the token. If the web application is able to decrypt the token with the shared secret, it knows that the token must have been generated by the trusted STS.

Trust is at the heart of any security system. In an AD DS domain, each component of Windows trusts the local security subsystem, which in turn trusts the domain, which in turn trusts other domains in the forest, and that trust can then be extended to other domains or forests. You can see an example of this trust in the Sidebar, "Trust and claims-based authentication in Action." In SharePoint, all web applications and services in a farm trust the Security Token Service (STS) of the farm.

Claims

When a claim is presented to a web application, the claim contains assertions about the user's identity. It also can contain claims about the user's group memberships. Each of the authentication methods available in claims-based authentication can provide the STS with an enumeration of the user's group memberships, which are added to the claim.

But a claim can provide more than just user and group information, and this is where claims become particularly valuable. Let's assume that you want to be able to send email messages to users from a website. How do you determine a user's email address? You can build and maintain a local database of user email addresses, but in an AD DS domain, that information is stored in AD, and so you would need to synch a local database with changes made in AD. Or you can add code to query AD each time you need an email address. Both approaches require additional work by the application developer.

A claim can include a user's email address or any other attribute of the user, such as the user's manager, manager's email address, department, job title, age, or gender. As long as the STS and web application are configured properly, the STS will collect attributes and bundle those attributes into a claim. Because the claims are presented by the user to the web application, the web application doesn't need to maintain local copies of the attributes, nor does it need to look up the attributes in an external source.

Claims-based authentication thus reduces the burden on applications to maintain or look up information about users. Attributes in claims can be used for a variety of purposes. The user's email address claim can be used to send the user an alert. The user's age claim can be used to provide access to age-restricted content. The user's manager claim can be used to get approval for a vacation request in a workflow.

You can also assign content permissions that are based on a claim. For example, you can specify that users must have a job title of vice president or higher to access content. You can also use claims to look up users. For example, if you want to assign a task to a user, but you can remember only the user's manager, the picker control can expose the manager attribute of users who belong to the site. Developers are particularly excited about the possibilities that are presented now that SharePoint 2010 supports claims.

Federation

Let's assume that certain content in a web application can be accessed only by users who are employees of your company, Contoso, or of a partner company, Litware. How do you make this work? It would be a burden to have duplicate copies of all Litware user accounts in your AD DS domain or in a separate database, and to keep changes in synch. It would be much easier to rely on the administrators at Litware to maintain their user accounts and to trust the authentication performed by Litware.

With Windows domains, you could configure a trust whereby the Contoso domain trusts the Litware domain. However, firewalls can prevent trusts from being correctly established and maintained, and many organizations have policies that forbid Windows trusts to external organizations.

Claims-based authentication supports federation (provided by solutions like Microsoft's ADFS or Ping Identity's PingFederate), which extends the concepts of trust and claims to third parties. For example, you can configure ADFS 2.0 to authenticate users against both domains, without requiring a trust. You then configure SharePoint's STS to trust the STS exposed by ADFS 2.0. From a terminology perspective, SharePoint's STS becomes the relying party STS (RP STS) and the STS of ADFS 2.0 becomes the identifying party STS (IP STS).

When a user attempts to access a website, the website redirects the user to the IP STS for authentication. The SAML token issued by the IP STS (ADFS 2.0 in this example) is then presented to the RP STS (SharePoint's STS in this example), which can augment the token with additional claims before giving the client the token that is then submitted to the web application.

Another example of federated identity is Windows Live ID authentication. You can configure SharePoint's STS to trust tokens that Windows Live ID issues.

SAML Tokens

SAML tokens can include any number of claims about a user, such as a username and groups to which the user belongs, as well as descriptive attributes. The relying party application receives the SAML token and uses the claims inside to decide whether to grant the client access to the requested resource. Therefore, one of the claims in the token must uniquely identify the user. This is called the identity claim. The IP-STS doesn't need to create the identity claim with the username submitted when the user logs on to the IP-STS. For example, AD FS doesn't have to create the identity claim with a user's domain username. The IP-STS can instead create the identity claim using another unique identifier. Many implementations of claims use the email address attribute as the identity claim. The RP-STS must know which claim is guaranteed to be unique for tokens created by the IP-STS.

For this reason, configuration of a claims environment using SAML token-based authentication requires cooperation between the administrators of the RP-STS and IP-STS. The following elements must be coordinated:

Implementing SAML token-based authentication with SharePoint 2010 Products involves the following processes:

You can configure multiple SAML token-based authentication providers. However, you can use a token-signing certificate only once in a farm. All configured providers will appear as options in Central Administration. Claims from different trusted STS environments won't conflict.

If you're implementing SAML token-based authentication with a partner company and your own environment includes an IP-STS, I recommend that you work with the administrator of your internal claims environment to establish a trust relationship from your internal IP-STS to the partner STS. The result is a type of chain of trust and authentication, in which your SharePoint applications trust your IP-STS, and your IP-STS trusts the partner IP-STS, thereby ensuring that authentication (e.g., the maintenance of user identities) is administered by each organization independently. This approach doesn't require adding another authentication provider to your SharePoint Server 2010 farm. It also allows your claims administrators to manage the entire claims environment.

Note: If you use SAML token-based authentication with AD FS on a SharePoint Server 2010 farm that has multiple web servers in a load-balanced configuration, there might be an effect on the performance and functionality of client web-page views. When AD FS provides the authentication token to the client, that token is submitted to SharePoint Server 2010 for each permission-restricted page element. If the load-balanced solution isn't using affinity, each secured element is authenticated to more than one SharePoint Server 2010 server, which might result in rejection of the token. After the token is rejected, SharePoint Server 2010 redirects the client to re-authenticate back to the AD FS server. After this occurs, an AD FS server might reject multiple requests that are made in a short time period. This behavior is by design, to protect against a denial of service (DoS) attack. If performance is adversely affected or pages don't load completely, consider setting network load balancing to single affinity. This isolates the requests for SAML tokens to a single web server.

You can find the details for each of these procedures on TechNet in the SharePoint 2010 Technical Library.

Claims-based authentication offers the ability to extend both authentication and the collection of attributes about a user to sources beyond an application and beyond your domain. Whether your first experience of claims-based authentication is with SharePoint 2010, ADFS, or Azure, it's well worth mastering the concepts.