Understanding Claims-Based Authentication

Claims-based authentication for SharePoint 2010 is built by using the Windows Identity Foundation (WIF) framework. WIF is a set of .NET Framework classes that are used to implement a claims-based identity. Claim-based authentication was developed to provide better fine-grained security for a role-based security model. Most systems, including SharePoint 2007 and its predecessors, use role (or group)-based security. Complex systems can use claims-based security to assign permissions on other attributes (claims) associated with users, such as city or membership in a distribution list.

Claims-based authentication in SharePoint 2010 provides a flexible and extensible authentication system that supports authentication for any identity management system that supports claims authentication. Claims-based authentication offers several benefits, including the following:

• Further decoupling SharePoint 2010 from the authentication providers.

• Allows SharePoint 2010 to support multiple authentication providers for a single URL.

• Allows identities to be passed (and impersonated) between systems without Kerberos delegation.

• Enables organizations to use Federation to collaborate.

• Allows ACLs to be configured using other membership objects and containers, such as distribution lists, audiences, and organizational units.

• Organizations can connect to non-Windows-based identity management systems that support claims.

• Provides a common model for performing identity operations for web browsers, web services, and other browser-based applications, including the Office suite.

The Claims Authentication Process

Claims authentication provides the benefit of being simple for authentication purposes, but under the covers the process has several components that work together. Claims authentication model has three main components: the identity provider, the relying party, and the user who was authenticated. Each of the three components interacts in the authentication process by exchanging information and claims.

The goal of any authentication process is to establish an identity. An identity is a security principal of an authorized user. The primary component in the claims-based authentication process is a security token that uses the Security Assertion Markup Language (SAML). The security token is used to securely identify and describe an identity by containing of a set of claims (identity assertions) for the identity. A claim is an attribute that is specific to the identity, such as an employee ID, employee title, or username. The claims are used to determine the level of access the identity has to specific SharePoint 2010 resources.

Both the identity provider and the relying party are implemented as Security Token Services where each performs a particular role in the authentication process. The Security Token Service (STS) illustrated in Figure 13.4 handles the exchange of claims, and it builds, signs, and issues the security tokens that can be used to authenticate and authorize an identity. The STS uses a policy to determine the contents of a security token. The policy is a collection of claims and claim rules that has been agreed upon between one or more STSs and the SharePoint web application, as illustrated in Figure 13.5. Policies are available in a policy store and are accessed by an STS, based on the requirements of the calling web application. The attribute stores are made of the various identity systems and providers containing the user account information, such as Active Directory Domain Services (AD DS,) ASP.NET authentication providers, and other SAML token-compliant authentication providers. The STS can perform two roles in the authentication process: the identity provider STS and the relying party STS.

Figure 13.4. Secure Token Service.

Figure 13.5. Claims authentication roles.

Identity Provider Security Token Service (IP-STS)

The IP-STS is the identity provider that provides the claim based on the information the user has provided. In SharePoint, the IP-STS is the local identity provider for the requesting web application. The IP-STS receives the authentication request and processes the request. The IP-STS finds the policy for the requesting web application or relying party STS, and creates a security token using the identity claims in the appropriate attribute store.

Relying Party Security Token Service (RP-STS)

The RP-STS is the identity provider that has an established trust relationship with the IP-STS. The RP-STS is used to validate the claims of external users whose credentials are not stored in the local attribute stores. The RP-STS creates security token for the authenticating user and the local SharePoint STS validates the claims for the authenticating user. The requesting web application authorizes the authenticated external user after the local SharePoint STS has validated the claims.

Claims Authentication in SharePoint

In SharePoint 2010, claims-based authentication is a SharePoint service. SharePoint contains a local STS as part of the SharePoint farm. A trust relationship exists between the local SharePoint STS and the SharePoint farm web applications.

Figure 13.6 illustrates a sequence of events when a user authenticates in SharePoint using claims-based authentication:

• The user attempts to connect to a SharePoint web application using a client (a web browser or office client). The client sends a web request to the web application for a particular resource.

• The SharePoint web application using claims-based authentication responds with a 302 response that includes a URL to redirect and authenticate.

• The client redirects and submits an authentication request to the URL for a security token. The authentication request is processed by the local STS. The local STS performs the role of the identity provider STS, authenticates the identity of the user, and creates a security token (SAML token) for the authenticated identity.

• The client receives a security token from the local STS.

• The client sends a web request to the web application for a particular resource with the security token included. The web application validates the user identity and retrieves the resources.

• The client receives access the resources it requested, such as a cookie, the HTML page, and its resources.

Figure 13.6. SharePoint claims authentication process.

Claims Authentication in SharePoint Using Federation

A common scenario for collaborating with partners is to create a trust between the partner STS and the local STS. When external users attempt to authenticate in SharePoint, the request will be made against the partner STS and validated by the local STS in the SharePoint farm. The external user will be able to access the web application with their external credentials.

Figure 13.7 shows the sequence of events when an external user authenticates in SharePoint using claims-based authentication:

• The user attempts to connect to a SharePoint web application using a web browser or Office client. The client makes a web request to the web application.

• The SharePoint web application that uses claims-based authentication responds with a 302 response that includes a URL to redirect to the appropriate partner STS and authenticate.

• The client redirects and submits an authentication request to the partner STS for a security token. The authentication request is processed by the partner STS, authenticates the identity of the user, and creates an identity provider security token (IP-STS token). The IP-STS token is sent to the local STS for validation.

• The local STS receives the IP-STS token and validates the claims for the identity. The local STS creates a new RP-STS token and sends it to the client. The RP-STS token includes additional claims from SharePoint to identify the user within SharePoint.

• The client receives the RP-STS token from the local STS.

• The client sends a web request to the web application for a particular resource with the RP-STS token included. The web application validates the user identity and retrieves the resources.

• The client receives access the resources it requested, such as a cookie, the HTML page, and its resources.

Figure 13.7. SharePoint claims authentication process using federation.