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
