Microsoft Sharepoint 2013 : User Authentication (part 2) - Using Claims-Based Identity

Using Claims-Based Identity

The purpose of this section is to show how claims identity is used to authenticate users. It begins with a real-world analogy that illustrates the use of claims. Then you will learn the technical requirements for implementing claims authentication. Finally, you will walk through the actual claims authentication process.

A Real-World Analogy

It’s very likely that at some point, you have used your driver’s license to establish or verify your identity. Your license contains a set of attributes that assert your identity, such as name, age, eye color, and so on. In order to obtain such a license, prospective drivers must furnish required credentials bearing proof of their identity. This proof might be a birth certificate, a passport, and might even include a utility bill or some other proof of residency. These assertions are verified by the state agency, and the state issues your driver’s license. This list of identity assertions is used by other companies or agencies to verify your identity because they trust the state agency that issued your license.

In claims identity, this list of assertions can be considered a set of claims. Assertions can include a username, a role, an employee ID, and a variety of other attributes pertinent to the individual’s position. The state agency represents the Security Token Service (STS). Users request access to SharePoint resources and are redirected to the STS. The STS verifies their identity (authenticates the user), and then issues a security token that encapsulates the user’s claims. The STS functions as an identity provider (IdP) because it creates and manages security tokens. To create a security token, the STS must be able to locate valid credentials for a user in an attribute store. Active Directory Domain Services can be used as an attribute store for an STS, and would be an example of an authentication provider. SharePoint and other applications trust the STS and therefore do not have to re-authenticate the user. The claims can then be used to determine authorization and permission levels for access to SharePoint 2013 resources.

A relying party is any entity that trusts the issuer of the driver’s license or, in the claims world, the STS. In the physical world, the security agent at the airport is a relying party. In the claims world, SharePoint trusts the STS (or multiple STSs) to have authenticated the users who make requests for SharePoint resources, and therefore is a relying party. In both the real world and the claims world, those who produce the security tokens often add other relevant information about the user to the tokens. In the driver’s license example, address information, height, weight, and a picture are typically included. In the claims world, security tokens can include information that SharePoint can use to authorize the user’s requests for SharePoint resources, such as organization information, group memberships based on geography or job role, or any other information that can be used to determine what a user can do inside of SharePoint. In our driver’s license analogy, the relying party of a driver’s license depend on the birthdate to determine whether a user can purchase alcohol. Note that the relying party makes this decision based on the value of the birthdate, not just the presence of the birthdate. As a relying party, SharePoint uses attributes gathered from Active Directory and other attribute stores. In the case of the driver’s license and the security token, these attributes are added when the token or license is created. This addition of claims is referred to as claims augmentation.

Driver’s licenses expire, and once expired they are no longer considered a legitimate means of providing identification. Similarly, a security token has a defined lifetime after which it is no longer valid.

Driver’s licenses are also subject to being modified or duplicated to provide false information. Relying parties in the physical world (security agents at an airport, for instance) deal with this by not accepting licenses that show signs of tampering. In the claims world, the STS knows the type and number of claims specified by the relying party, and the STS token is digitally signed to protect against tampering and ensure authenticity.

Technical Requirements

To implement claims identity, SharePoint 2013 utilizes a Security Token Service (STS) defined in WS-Trust, and is configured to trust one or multiple STSs. SharePoint 2013 is claims-enabled once it is installed, but the following provides perspective on the key components. Implementing claims-based identity and using claims for authorization generally requires using and understanding a set of core technologies:

• Windows Identity Framework (WIF) — WIF provides the .NET classes required to enable claims-based authentication. All the required interactions with the security infrastructure (Active Directory, LDAP directories, cloud-based directory services such as Windows Azure Access Control Service, etc.) are enabled by WIF. WIF is based on a set of open-source standards, and specifically includes capability for WS-Security, WS-Trust, and WS-Federation. WIF is part of the SharePoint 2013 prerequisites, and it is automatically installed when you run the prerequisite installer.
• Security Assertion Markup Language (SAML) — SAML is a markup language that is the recognized standard for communicating identity information. WIF officially supports SAML 1.1, although support for SAML 2.0 is currently available via a Community Technical Preview (CTP) from Microsoft.
• Open Authorization 2.0 (OAuth) — OAuth is a protocol that enables users to authorize access to resources without user credentials (user ID and password, certificates, etc.). The user is required to authorize this access when it is first requested. Subsequent access is considered to be acceptable to the end user. Access is granted to specific resources for a specific duration. OAuth is the protocol used to allow SharePoint applications from the Office Store or an organization’s application store (known as the App Catalog) to access SharePoint resources on behalf of the user or the application principal. OAuth is used to allow applications that are running outside of SharePoint to access protected SharePoint resources.
• Active Directory Federated Services 2.0 — ADFS 2.0 provides both identity federation and single sign-on (SSO) solutions. ADFS is an STS. It uses Active Directory as its identity store; and Lightweight Directory Access Protocol (LDAP), SQL, or a custom store as an attribute store. ADFS is not required for SharePoint 2013, but it enables SharePoint 2013 to federate with other applications. ADFS also provides SAML 2.0 support, and it can be used with SharePoint 2013 to deliver this capability.

Claims-based authentication is user authentication that utilizes claims-based identity. Users can have identities in different directory stores and use them simultaneously to access different resources in SharePoint. Claims-based authentication is the default for SharePoint 2013. SharePoint 2013 supports Windows claims (NTLM and Kerberos), FBA claims, and SAML 1.1 claims. In order to use SAML 2.0, SharePoint 2013 must federate with ADFS, which supports both SAML 1.1 and SAML 2.0. Using claims-based authentication enables you to take advantage of all the new capabilities in SharePoint 2013.