UNDERSTANDING CLAIMS-BASED IDENTITY

For people who create applications, working with identity traditionally hasn’t been much fun. First, a developer needs to decide which identity technology is right for a particular application. If the application will be accessed in different ways, such as within an organization, across different organizations, and via the public Internet, one identity technology might not be enough—the application might need to support multiple options. The developer also needs to figure out how to find and keep track of identity information for each of the application’s users. The application will get some of what it needs directly from those users, but it might also need to look up other information in a directory service or someplace else. IT administrators must also be involved to configure this software correctly. Add the cloud to the mix, and things get even more complicated.

This is all more complex than it needs to be. Why not create a single interoperable approach to identity that works in pretty much every situation, both on-premises and in the cloud? And rather than making applications hunt for identity information, why not make sure that this single approach lets users supply each application with the identity information it requires?

Claims-based identity achieves these goals. It provides a common way for applications to acquire the identity information they need about users inside their organization, in other organizations, and on the Internet. It also provides a consistent approach for applications running on-premises or in the cloud.

Taking advantage of claims-based identity requires developers to understand how and why to create claims-based applications. It also requires infrastructure software that applications can rely on. This overview describes the basics of claims-based identity, then looks at how a group of Microsoft technologies help make this world a reality. Those technologies are Active Directory Federation Services (AD FS) 2.0, the Windows Azure AppFabric Access Control service (ACS), and Windows Identity Foundation (WIF).

THE PROBLEM: WORKING WITH IDENTITY IN APPLICATIONS

Sometimes, working with identity is simple. Think of a Windows application that doesn’t need to know much about its users, for example, and that will be accessed only by people within a single organization. This application can just rely on Windows Integrated Authentication (WIA), which uses Kerberos under the covers. Kerberos is implemented as part of Active Directory Domain Services (AD DS, originally known as just “Active Directory”), and it provides a way to authenticate users and convey basic information about them. Or suppose you’re creating an application that will be accessed solely by Internet users. Again, the common approach to handling identity is straightforward: just require each user to supply a username and password.  Yet the requirements for modern applications are rarely this simple. What if you need more information about each user than is provided by either Kerberos or a simple username and password? Your application will now need to acquire this information from some other source, such as AD DS, or keep track of the information itself. Or suppose the application must be accessed both by employees inside the organization and by customers via the Internet—what now? Should the application support both Kerberos and username/password-based logins? And what about the case where you’d like to let users from a business partner access this application without requiring a separate login? This kind of access can’t be accomplished very well with either Kerberos or username/password logins—more is required. 4

The right solution is to have one approach to identity that works in all of these scenarios. To be effective, this single approach must be based on widely recognized industry standards that interoperate across both platform and organizational boundaries. But standards alone aren’t enough. The solution also needs to be widely implemented in products from multiple vendors and be simple for developers to use. This unified, broadly supported approach is exactly what claims-based identity is meant to provide.

Claims-based identity is a straightforward idea, founded on a small number of concepts: claims, tokens, identity providers, and a few more. This section describes the basics of this technology, starting with a look at these fundamental notions. Before launching into this description, however, there’s an important point to make. While this paper focuses on the mechanics, using the technology described here can require more, such as business agreements between different organizations. Addressing the technical challenges is essential, but they’re not always the whole story.

Federation Providers

In a claims-based world, a user always initially gets her identity from an STS owned by some identity provider. But suppose the application she wants to access doesn’t trust this STS—what then? One possibility is that there’s just no way for her to access this application. There’s also another option, however: even though the application she wants to access doesn’t trust her STS, it might trust another STS that in turn trusts her STS. This approach, called identity federation, is both common and useful. With federation, an identity provider offers an STS as usual, but another STS is also offered by a federation provider (FP). The federation provider STS is then configured by an administrator to trust the identity

provider STS. Figure 5 shows how a user can provide identity information to an application when federation is used.

As always, the process begins when the user accesses an application from a browser or another client, learning which STSs that application trusts (step 1). Here, the application trusts only the federation provider STS. The user’s browser or client software then contacts that federation provider, learning which STSs it trusts (step 2). In this example, the federation provider STS is configured to trust the identity provider’s STS, and so the user’s browser or client software contacts this STS. As usual, the user is authenticated in some way, then gets back an IdP token created by this STS (step 3).

This token can’t be used to access the application, however, since that application doesn’t trust the STS that issued it. Fortunately, this token can be used to acquire a token that the application will accept. To do this, the browser or client software sends the IdP token to the federation provider (step 4). The federation provider validates this token, ensuring that it came from an STS it trusts. Once it determines this, it creates a new token for this user (step 5), then returns this FP token (step 6). The user’s software submits this token to the application (step 7), which verifies that the FP token was issued by an STS that it trusts. The application then uses the claims in the token as usual (step 8).

From the user’s point of view, all of these exchanges are invisible. She accesses the application without explicitly logging into it, that is, she gets what’s known as single sign-on. The mechanics are a little more complex, but the core idea underlying identity federation is straightforward. It is that not only applications can trust STSs; one STS can trust another STS as well.

Step 5 in the figure is worth examining in more detail. As just described, the federation provider receives a token issued by another STS, then generates a new token for the user. But exactly what claims does this 10

new token contain? The answer depends on what the federation provider’s STS is configured to do. In the simplest case, it might copy every claim from the IdP token directly into the FP token unchanged. In a more realistic scenario, the federation provider STS performs claims transformation, emitting a token that doesn’t contain the exact set of claims that it received from the identity provider.

For example, suppose the IdP token contains a claim indicating that this user is a member of the role “Administrator”, expressing that claim as a character string containing this English word. It’s possible that the application understands the administrator role, but expects the claim to be expressed as a numeric code or in Chinese or in some other way. The federation provider can perform this translation, inserting a claim in the correct format in the FP token it generates.

Claims transformation can do other things as well. When it creates the FP token, for example, the federation provider might omit claims from the IdP token that aren’t meaningful to this application. Or it might add claims to the FP token that aren’t present in the IdP token, such as an indication of the IdP that issued the original token. Claims transformation is a powerful idea, and it can be used in a variety of ways