Claims-Based Identity Overview
For some applications, working with user identity is simple. Consider a Windows application that is accessed only by users in a single organization and does not need to know much about those users. This application can simply rely on Kerberos, part of Active Directory Domain Services (AD DS), to authenticate its users and convey basic information about them. Or consider an application that is accessed only by Internet users. This application can simply require each user to supply a username and password, and it can store this user information in a database.
However, for most applications, working with user identity is more complex. Consider an application that needs more information about each user than is provided by either Kerberos or a simple username and password. The application has to acquire this information from some other source, such as AD DS or store the information itself. Or consider an application that must be accessed both by employees inside the organization and by Internet users. The application must support both Kerberos and username and password based logins. Finally, suppose the application must be accessed by a different organization without requiring a separate login. This identity federation can’t be accomplished very well with either Kerberos or username and password logins.
The following diagram shows the problem of identity silos in a typical organization. As you can see, the user is forced to sign in separately just to access different applications in the user’s own domain, to say nothing of applications in other domains.
Claims-based identity provides one approach to identity that works in all of these scenarios. It is based on widely recognized industry standards that work across both platform and organizational boundaries. It is also widely implemented in products from multiple vendors, and it is simple for developers to use.
When you build claims-aware applications, the user presents an identity to your application as a set of claims. One claim could be the user’s name, another might be an e-mail address. The idea here is that an external identity system is configured to give your application everything it needs to know about the user with each request she makes, along with cryptographic assurance that the identity data you receive comes from a trusted source.
Under this model, single sign-on (SSO) is much easier to achieve, and your application is no longer responsible for the following:
Storing user accounts and passwords
Calling to enterprise directories to look up user identity details
Integrating with identity systems from other platforms or companies
Under this model, your application makes identity-related decisions based on claims supplied by the user. This could be anything from simple application personalization with the user’s first name, to authorizing the user to access higher valued features and resources in your application.
This section of the topic introduces terminology and concepts to help you understand this new architecture for identity.
The word “identity” is an often ambiguous term. For the purposes of describing the programming model in AD FS 2.0, we use the term identity to describe a set of attributes that describe a user or some other entity in a system that you want to secure.
Think of a claim as a piece of identity information, such as name, e-mail address, age, or membership in the Sales role. The more claims your application receives, the more you’ll know about your user. You may be wondering why these are called “claims,” rather than “attributes,” as is commonly used in describing enterprise directories. The reason has to do with the delivery method. In this model, your application doesn’t look up user attributes in a directory. Instead, the user delivers claims to your application, and your application examines them. Each claim is made by an issuer, and you trust the claim only as much as you trust the issuer. For example, you trust a claim made by your company’s domain controller more than you trust a claim made by the user herself.
The user delivers a set of claims to your application along with a request. In a Web service, these claims are carried in the security header of the Simple Object Access Protocol (SOAP) envelope. In a browser-based Web application, the claims arrive through an HTTP POST from the user’s browser. The claims may later be cached in a cookie if a session is desired. Regardless of how these claims arrive, they must be serialized, which is where security tokens come in. A security token is a serialized set of claims that is digitally signed by the issuing authority. The signature is important: it gives you assurance that the user didn’t just make up a bunch of claims and send them to you. In low-security situations where cryptography isn’t necessary or desired, you can use unsigned tokens, but that scenario is not described in this topic.
There are many different types of issuing authorities, from domain controllers that issue Kerberos tickets to certification authorities (CAs) that issue X.509 certificates. However, the specific type of authority discussed in this topic issues security tokens that contain claims. This issuing authority is a Web application or Web service that knows how to issue security tokens. It must have enough knowledge to be able to issue the proper claims given the target relying party and the user making the request, and it might be responsible for interacting with user stores to look up claims and authenticate the users themselves.
Whatever issuing authority you choose, it plays a central role in your identity solution. When you factor authentication out of your application by relying on claims, you’re passing responsibility to that authority and asking it to authenticate users on your behalf.
A security token service (STS) is the service component that builds, signs, and issues security tokens according to the WS-Trust and WS-Federation protocols. You can use a cloud STS such as a LiveID STS, a prebuilt STS such as Active Directory® Federation Services (AD FS) 2.0, or, if you want to issue custom tokens or provide custom authentication or authorization, you can build your own custom STS using Windows® Identity Foundation (WIF).
When you build an application that relies on claims, you are building a relying party (RP) application. Synonyms for an RP include “claims-aware application” and “claims-based application”. Web applications and Web services can both be RPs. An RP application consumes the tokens that a Security Token Service (STS) issues and extracts the claims from tokens to use them for identity-related tasks.
To make all of this interoperable, several WS-* standards are used in the previous scenario. Policy is retrieved using WS-MetadataExchange, and the policy itself is structured according to the WS-Policy specification. The STS exposes endpoints that implement the WS-Trust specification, which describes how to request and receive security tokens. Most STSs today issue tokens that are formatted with the Security Assertion Markup Langauge (SAML). SAML is an industry-recognized XML vocabulary that can be used to represent claims in an interoperable way. Or, in a multiplatform situation, this allows you to communicate with an STS on an entirely different platform and achieve SSO across all of your applications, regardless of platform.
Smart clients aren’t the only ones that can use the claims-based identity model. Browser-based applications (also referred to as passive clients) can use it as well. The following scenario describes how this works.
The following is an example of a claims-based system.
The previous illustration shows a claims-aware Web service (the RP application) and a smart client that wants to use that service. The RP exposes a policy that describes its addresses, bindings, and contracts. But the policy also includes a list of claims that the RP needs, such as user name, e-mail address, and role memberships. The policy also tells the smart client the address of the STS from which it should retrieve these claims. After retrieving this policy (1), the client now knows where to go to authenticate: the STS. The user presents credentials (2), and the smart client makes a Web service request (3) to the STS, requesting the claims that the RP asked for in its policy. The job of the STS is to authenticate the user and return a security token that gives the RP all of the claims it needs. The smart client then makes its request to the relying party (4), sending the security token along in the security SOAP header. The RP now receives claims with each request, and it simply rejects any requests that don’t include a security token from the issuing authority that it trusts.