Understanding Claims-Based Authentication
If you have not worked with claims-based authentication before, you may be unfamiliar with some of the terminology. This topic provides a brief review of the key concepts and terms. When you use claims-based authentication your application, in this case a SharePoint web application, relies on an external identity management system to authenticate users and provide any required information about each user. An application that relies on claims-based authentication is said to be claims-aware. As a claims-aware application, the SharePoint web application relies on a trust relationship with the identity management system. This trust relationship is essentially configured through the exchange of security certificates for public-key cryptography.
When the trusted identity management system sends an encrypted identity token to the SharePoint web application, SharePoint knows that:
- The identity management system has authenticated the user.
- Any information about the user, such as his or her user name and role memberships, is valid.
When you work with claims-aware applications such as SharePoint, you are likely to encounter the following terms:
- Claim. A claim is an individual piece of information about a user, such as a name, an email address, or a role membership. A claims-aware application will only believe a claim if it trusts the identity management system that issued the claim.
- Security token. A security token is a serialized set of claims that is digitally signed by the issuing authority. Security tokens are presented to claims-aware applications alongside requests and they enable the application to authorize access to resources.
- Issuing authority. The issuing authority is the external identity management system that issues security tokens. Claims-aware applications trust the claims made in security tokens if they trust the issuing authority. Issuing authorities are sometimes referred to as claims providers.
- Security token service (STS). An STS is a web service that creates and issues digitally-signed security tokens. In the case of an issuing authority, the STS is known as an Identity Provider STS (IP-STS). When you federate identities among multiple systems to support single sign-on (SSO) scenarios, you also rely on a Relying Party STS (RP-STS). A RP-STS receives identity tokens from a remote IP-STS, validates the tokens based on the trust relationship among the STSs and issues a new security token to provide access to local claims-aware applications and services.
- Relying party. A relying party is another term for a claims-aware application. The relying party is able to extract and use claims from a security token. After configuring a trust relationship between a claims-aware application and an issuing authority, you must typically register your application as a relying party with the issuing authority in order to configure how claims are presented to yourapplication.
- Security Assertion Markup Language (SAML). SAML is an open, XML-based standard that represents claims in an interoperable format. Most STSs issue security tokens in SAML format. This enables you to exchange and use security tokens across disparate platforms. In ASP.NET applications such as SharePoint, the claims infrastructure is implemented by Windows Identity Foundation (WIF) and the .NET Framework. WIF implements open web standards to ensure interoperability with other platforms. For example, WIF-based STSs expose service endpoints that support the WS-Trust specification, that describes how to request and receive security tokens. The SharePoint Security Token Service Application in claims-based authentication terms is an STS web service that issues security tokens that represent a verified user identity. These tokens consist of one or more identity claims, such as the user's account name, email address, or group memberships. There are two key types of STSs:
- An Identity Provider STS (IP-STS) is used to create and manage claims-based identities. An IP-STS validates user credentials against an identity store, such as AD DS, that does claims aggregation and issues a claims-based security token.
- A Relying Party STS (RP-STS) receives security tokens from an IP-STS, where a trust relationship has been configured between the two STSs. The RP-STS validates that a received security token is trusted and then it issues a new security token to provide access to local resources. In SharePoint 2013, as in SharePoint 2010, the Security Token Service Application provides the core functionality of an STS. The Security Token Service Application performs the role of both an IP-STS and an RP-STS, depending on the scenario. The functionality of the Security Token Service Application underpins many SharePoint 2013 features. For example:
- When you sign in to a web application using Windows credentials, the Security Token Service Application converts your Windows identity into a claims identity. It augments the claims with information from AD DS, where appropriate and issues a claims-based security token.
- When you configure a connection between your SharePoint server farm and another server platform, such as Office Web Apps Server 2013 or Exchange Server 2013, you configure a trust relationship between the SharePoint STS and the remote STS. The Security Token Service Application provides IPSTS functionality if SharePoint is requesting information from another platform, or RP-STS functionality if another platform is requesting information from SharePoint.
- When you configure a SharePoint web application to allow SAML token–based authentication, the token issuer is the IP-STS and the Security Token Service Application is the RP-STS.The Security Token Service Application is provisioned automatically when you create a SharePoint 2013 server farm. You cannot configure the service and you do not need to create service application connections or proxies for the service.