2 3
The following table shows the relationships between security to-
kens, claims, and issuers.
Security token Claims Issuer
Windows token. This
token is represented as a
security identifi er (SID).
This is a unique value of
variable length that is
used to identify a
security principal or
security group in
Windows operating
systems.
User name and groups. Domain.
User name token. User name. Application.
Certifi cate. Examples can include a
thumbprint, a subject, or
a distinguished name.
Issuer chains to the root.
The claims-based approach to identity makes it easy for users to sign
in using Kerberos where it makes sense, but at the same time, it’s just
as easy for them to use one or more (perhaps more Internet-friendly)
authentication techniques, without you having to recode, recompile,
or even reconfi gure your applications. You can support any authenti-
cation technique, some of the most popular being Kerberos, forms
authentication, X.509 certifi cates, smart cards, as well as information
cards and others.
This is an important disclaimer. Companies with a host of internal ap-
plications can use Windows Integrated authentication to achieve
many of the benefi ts provided by claims. Active Directory does a great
job of storing user identities, and because Kerberos is a part of Win-
dows, your applications don’t have to include much authentication
logic. As long as every application you build can use Windows inte-
grated authentication, you may have already reached your identity
utopia.
However, there are many reasons why you might need something
other than Windows authentication. You might have Web-facing ap-
plications that are used by people who don’t have accounts in your
Windows domain. Another reason is that your company has merged
with another company and you’re having trouble authenticating across
two Windows forests that don’t (and may never) have a trust relation-
ship. Perhaps you want to share identities with another company that
has non-.NET Framework applications or you need to share identities
between applications running on different platforms (for example, the
Macintosh). These are just a few situations where claims-based iden-
tity can be the right choice for you.
Most applications include a certain amount of logic that supports
identity-related features. Applications that can’t rely on Windows In-
tegrated authentication tend to have more of this than applications
that do. For example, Web-facing applications that store user names
and passwords must handle password reset, lockout, and other issues.
Enterprise-facing applications that use Windows Integrated authenti-
cation can rely on the domain controller.
But even with Windows Integrated authentication, there are still
challenges. Kerberos tickets only give you a user’s account and a list
of groups. What if your application needs to send e-mail to the user?
What if you need the e-mail address of the user’s manager? This starts
to get complicated quickly, even within a single domain. To go beyond
Kerberos’s limitations, you need to program Active Directory. This is
not a simple task, especially if you want to build effi cient Lightweight
Directory Access Protocol (LDAP) queries that don’t slow down your
directory server.
Claims-based identity allows you to factor out the authentication
logic from individual applications. Instead of the application determin-
ing who the user is, it receives claims that identify the user.
Claims-based identity is all around us. A very familiar analogy is the
authentication protocol you follow each time you visit an airport. You
can’t simply walk up to the gate and present your passport or driver’s
license. Instead, you must fi rst check in at the ticket counter. Here,
you present whatever credential makes sense. If you’re going overseas,
you show your passport. For domestic fl ights, you present your driv-
er’s license. If your children fl y with you, they don’t need to show
anything at all, but the ticket agent asks you their names to provide
some level of authentication. After verifying that your picture ID
matches your face, the agent looks up your fl ight and verifi es that
you’ve paid for a ticket. Assuming all is in order, you receive a boarding
pass that you take to the gate.
A boarding pass is very informative. Gate agents know your name
and frequent fl yer number (authentication and personalization), your
fl ight number and seating priority (authorization), and perhaps even
more. The gate agents have everything that they need to do their jobs
effi ciently.
You can use claims to
implement Role-
Based Access Control
(RBAC). Roles are
claims, but claims can
contain more
information than
roles. Also, you can
send claims inside a
signed (and possibly
encrypted) security
token and be certain
that they come from
a trusted issuer.
╭
Claims provide a
powerful abstraction
for identity.
╭
Claims help you to factor
authentication logic out
of your applications.