The Web is full of interactive applications that users can visit by simply clicking a hyperlink. Once they do, they expect to see the page they want, possibly with a brief stop along the way to log on. Users also expect Web sites to manage
their logon sessions, although most of them wouldn't phrase it that way. They would just say that they don't want to retype their password over and over again as they use any of their company's Web applications. For claims to flourish on the Web,
it's critical that they support this simple user experience, which is known as single sign-on.
If you've been a part of a Windows domain, you're already familiar with the benefits of single sign-on. You type your password once at the beginning of the day, and that grants you access to a host of resources on the network. Indeed, if you're
ever asked to type your password again, you're going to be surprised and annoyed. You've come to expect the transparency provided by Windows Integrated authentication.
Ironically, the popularity of Kerberos has led to its downfall as a flexible, cross-realm solution. Because the domain controller holds the keys to all of the resources in an organization, it's closely guarded by firewalls. If you're away from work,
you're expected to use a VPN to access the corporate network. Also, Kerberos is inflexible in terms of the information it provides. It would be nice to extend the Kerberos ticket to include arbitrary claims such as the user's e-mail address, but this
isn't a capability that exists right now.
Claims were designed to provide the flexibility that other protocols may not. The possibilities are limited only by your imagination and the policies of your IT department. The standard protocols that exchange claims are specifically designed to cross boundaries
such as security realms, firewalls, and different platforms. These protocols were designed by many who wanted to make it easier to securely communicate with each other.
Claims decouple your applications from the details of identity. It's no longer the application's responsibility to authenticate users. All your application needs is a security token from the issuer that it trusts. Your application won't break if
the IT department decides to upgrade security and require users to submit a smart card instead of submitting a user name and password. In addition, it won't need to be recoded, recompiled, or reconfigured.
There's no doubt that domain controllers will continue to guard organizational resources. Also, the business challenges, such as how to resolve issues of trust and how to negotiate legal contracts between companies who want to federate identity, remain.
Claims-based identity isn't going to change any of that. However, by layering claims on top of your existing systems, you can remove some of the technical hurdles that may have been impeding your access to a broad, flexible single sign-on solution.
A Closer Look at Claims-Based Architectures
There are several architectural approaches you can use to create claims-based applications. For example, Web applications and SOAP Web services each use slightly different techniques, but you'll quickly recognize that the overall shapes of the handshakes
are very similar because the goal is always the same: to communicate claims from the issuer to the application in a secure fashion. This chapter shows you how to evaluate the architectures from a variety of perspectives, such as the user experience, the performance
implications and optimization opportunities, and how the claims are passed from the issuer to the application. The chapter also offers some advice on how to design your claims and how to know your users.
The goal of many of these architectures is to enable federation with either a browser or a smart client. Federation with a smart client is based on WS-Trust and WS-Federation Active Requestor Profile. These protocols describe the flow of communication between
smart clients (such as Windows-based applications) and services (such as WCF services) to request a token from an issuer and then pass that token to the service for authorization.
Federation with a browser is based on WS-Federation Passive Requestor Profile, which describes the same communication flow between the browser and Web applications. It relies on browser redirects, HTTP GET, and POST to request and pass around tokens.
The Microsoft® Windows Identity Foundation (WIF) is a set of .NET Framework classes that allow you to build claims-aware applications. Among other things, it provides the logic you need to process WS-Federation requests. The WS-Federation protocol builds
on other standard protocols such as WS-Trust and WS-Security. One of its features is to allow you to request a security token in browser-based applications.
WIF makes claims seem much like forms authentication. If users need to sign in, WIF redirects them to the issuer's logon page. Here, the user is authenticated and is then redirected back to the application. Figure 1 shows the first set of steps that allow
someone to use single sign-on with a browser application.
Single sign-on with a browser, part 1
If you're familiar with ASP.NET forms authentication, you might assume that the issuer in the preceding figure is using forms authentication because it exposes a page named Login.aspx. But this page may simply
be an empty page that is configured in Internet Information Server (IIS) to require Windows Integrated authentication or a client certificate or a smart card. An issuer should be configured to use the most natural and secure method of authentication for the
users that sign in there. Sometimes a simple user name and password form is enough, but obviously this requires some interaction and slows down the user. Windows Integrated authentication is easier and more secure for employees in the same domain as the issuer.
When the user is redirected to the issuer's log-on page, several query string arguments are passed that act as instructions to the issuer. Here are two of the key arguments with example values:
argument stands for "action," and says one of two things—whether you're logging on (wsignin1.0) or logging off (wsignout1.0).
argument stands for "target realm" and contains a Uniform Resource Indicator (URI) that identifies the application. The issuer uses the URI to identify the application the user is logging on to. The URI also allows the issuer to
perform other tasks, such as associating the claims for the application and replying to addresses.
After the issuer authenticates the user, it gathers whatever claims the application needs (using the
parameter to identify the target application), packages them into a security token, and signs the token with its private key. If the application wants its tokens encrypted, the issuer encrypts the token with the public key in the application's
Now the issuer asks the browser to go back to the application. The browser sends the token to the application so it can process the claims. Once this is done, the user can begin using the application.
To accomplish this, the issuer returns an HTML page to the browser, including a
element with the form-encoded token inside. The form's action
attribute is set to submit the token to whatever URL was configured for the application. The user doesn't normally see this form because the issuer also emits a bit
Single sign-on with a browser, part 2
Now consider this process from the user's experience. If the issuer uses Windows Integrated authentication, the user clicks the link to the application, waits for a moment while the browser is first redirected
to the issuer and then back to the application, and then the user is logged on without any additional input. If the issuer requires input from the user, such as a user name and password form or a smart card, users have a brief pause to log on, and then they
can use the application. From the user's point of view, the logon process with claims is the same as what he or she is to, which is critical.
Understanding the Sequence of Steps
The steps illustrated in the preceding illustrations can also be depicted as a sequence of steps that occur over time. Figure 3 shows this sequence.
Browser-based message sequence
If a user is not authenticated, the browser requests a token from the issuer, which in this case is Active Directory Federation Services (ADFS). ADFS queries Active Directory for the necessary attributes and returns a signed
token to the browser.
After the POST arrives at the application, WIF takes over. The application has configured a WIF HTTP module, named
(FAM), to intercept this POST to the application and handle the processing of the token. The FAM listens for the
event. The event handler performs several validation steps, including checking the token's audience restriction and the expiration date. Audience restriction is defined by the
element. It determines the URIs the application can accept in the token. The FAM also uses the issuer's public key to make sure that the token was signed by the trusted issuer and was not modified in transit. Then it parses the claims
in the token and uses the HttpContext.User.Identity
property (or equivalently the
property) to present an IClaimsPrincipal
object to the application. It also issues a cookie to begin a logon session, just like what would happen if you were using forms authentication instead of claims. This means that the authentication
process isn't repeated until the user signs off or otherwise destroys the cookie or until the session expires (sessions are typically designed to last for a single work day).
Figure 4 shows the steps that WIF takes for the initial request, when the application receives a token from the issuer.
Cannot resolve image macro, invalid image name or id.
Sequence of steps for initial request
One of the steps that the FAM performs is to create the session token. On the wire, this translates into a sequence of cookies named
. These cookies are the result of compressing, encrypting, and encoding the
object, along with any other attributes. The cookies are chunked to avoid overstepping any size limitations.
Figure 5 shows what the network traffic looks like for the initial request.
Sequence of cookies
On subsequent requests to the application, the SessionAuthenticationModule
intercepts the cookies and uses them to reconstruct the
object. Figure 6 shows the steps that WIF takes for any subsequent requests.
Steps for subsequent requests
Figure 7 shows what the network traffic looks like for subsequent requests.
Network traffic for subsequent responses
All of the steps, both for the initial and subsequent requests, should run over the Secure Sockets Layer (SSL) to ensure that an eavesdropper can't steal either the token or the logon session cookie and replay
them to the application in order to impersonate a legitimate user.
Are there opportunities for performance optimizations here? The answer is a definite "Yes." You can use the logon session cookie to cache some state on the client to reduce round-trips to the issuer. The issuer also issues its own cookie so that users
remain logged on at the issuer and can access many applications. Think about how this works—when a user visits a second application and that application redirects back to the same issuer, the issuer sees its cookie and knows the user has recently been authenticated,
so it can immediately issue a token without having to authenticate again. This is how to use claims to achieve Internet-friendly single sign-on with a browser-based application.
When you use a Web service, you don't use a browser. Instead, you use an arbitrary client application that includes logic for handling claims-based identity protocols. There are two protocols that are important in this situation: WS-Trust, which describes
how to get a security token from an issuer, and WS-Security, which describes how to pass that security token to a claims-based Web service.
Recall the procedure for using a SOAP-based Web service. You use the Microsoft Visual Studio® development system or a command line tool to download a Web Service Definition Language (WSDL) document that supplies the details of the service's address,
binding, and contract. The tool then generates a proxy and updates your application's configuration file with the information discovered in the WSDL document. When you do this with a claims-based service, its WSDL document and its associated WS-Policy
document supply all the necessary details about the issuer that the service trusts. This means that the proxy knows that it needs to obtain a security token from that issuer before making requests to the service. Because this information is stored in the configuration
file of the client application, at run time the proxy can get that token before talking to the service. This optimizes the handshake a bit compared to the browser scenario, because the browser had to visit the application first before being redirected to the
issuer. Figure 8 shows the sequence of steps for smart clients.
Smart client-based message sequence
The steps for a smart client are similar to those for browser-based applications. The smart client makes a round-trip to the issuer, using WS-Trust to request a security token. In step 1, The Orders Web service is configured
with the WSFederationHttpBinding
. This binding specifies a Web service policy that obligates the client to attach a SAML token to the security header to successfully invoke the Web service. This means that the client will first have to call the issuer
with a set of credentials such as a user name and password to get a SAML token back. In step 2, the client can call the Web service with the token attached to the security header.
Figure 9 shows a trace of the messages that occur in the smart client scenario.
Smart client network traffic
The WS-Trust request (technically named a Request for Security Token, or RST for short) includes a field named
, which allows the smart client to indicate a URI for the Web service it's ultimately trying to access. This is similar to the
query string argument used in the case of a Web browser. Once the issuer authenticates the user, it knows which application wants access and it can decide which claims to issue. Then the issuer sends back the response (RSTR), which includes a
signed security token that is encrypted with the public key of the Web service. The token includes a
. This is a symmetric key randomly generated by the issuer and included as part of the RSTR so that the client also gets a copy.
Now it's up to the client to send the token to the Web service in the <Security>
header of the SOAP envelope. The client must sign the SOAP headers (one of which is a time stamp) with the proof key to show that it knows the key. This extra
cryptographic evidence further assures the Web service that the caller was, indeed, the one who was issued the token in the first place.
At this point, it's typical to start a session using the WS-SecureConversation
protocol. The client will probably cache the RSTR for up to a day in case it needs to reconnect to the same service later on.
Federating Identity Across Realms
So far you've learned enough about claims-based identity to understand how to design and build a claims-based application where the issuer directly authenticates the users.
But you can take this one step further. You can expand your issuer's capabilities to accept a security token from another issuer, instead of requiring the user to authenticate directly. Your issuer now not only issues security tokens, but it also accepts
tokens from other issuers that it trusts. This enables you to federate identity with other realms (these are separate security domains), which is truly a powerful feature. Much of the federation process is actually accomplished by your IT staff, because it
depends on how issuers are configured. But it's important to be aware of these possibilities because, ultimately, they lead to more features for your application, even though you might not have to change your application in any way. Also, some of these
possibilities may have implications for your application's design.
The Benefits of Cross-Realm Identity
Maintaining an identity database for users can be a daunting task. Even something as simple as a database that holds user names and passwords can be painful to manage. Users forget their passwords on a regular basis, and the security stance taken by your company
may not allow you to simply e-mail forgotten passwords to them the way many low-security Web sites do. If maintaining a database for users inside your enterprise is difficult, imagine doing this for hundreds or thousands remote users.
Managing a role database for remote users is just as difficult. Imagine Alice, who works for a partner company and uses your purchasing application. On the day that your IT staff provisioned her account, she worked in the purchasing department, so the IT staff
assigned her the role of Purchaser, which granted her permission to use the application. But because she works for a different company, how is your company going to find out when she transfers to the Sales department? Or what if she quits? In both cases, you'd
want to know about her change of status, but it's unlikely that anyone in the HR department at her company is going to notify you.
It's unavoidable that any data you store about a remote user eventually becomes stale. How can you safely expose an application for a partner business to use?
One of the most powerful features of claims-based identity is that you can decentralize it. Instead of having your issuer authenticate remote users directly, set up a trust relationship with an issuer that belongs to the other company. This means that your
issuer trusts their issuer to authenticate users in their realm. Their employees are happy because they don't need special credentials to use your application. They use the same single sign-on mechanism they've always used in their company. Your application
still works because it continues to get the same boarding pass it needs. The claims you get in your boarding pass for these remote users might include less powerful roles because they aren't employees of your company, but your issuer will be responsible
for determining the proper assignments. Finally, your application doesn't need to change when a new organization becomes a partner. The fan-out of issuers to applications is a real benefit of using claims—you reconfigure one issuer and many downstream
applications become accessible to many new users.
Another benefit is that claims allow you to logically store data about users. Data can be kept in the store that is authoritative rather than in a store that is simply convenient to use or easily accessible.
Identity federation removes hurdles that may have stopped you from opening the doors to new users. Once your company decides which realms should be allowed access to your claims-based application, your IT staff can set up the proper trust relationships. Then
you can, for example, invite employees from a company that uses Java, to access your application without having to issue passwords for each of them. They only need a Java-based issuer, and those have been available for years. Another possibility is to federate
identity with Windows Live™, which supports claims-based identity. This means that anyone with a Windows Live ID can use your application.
How Federated Identity Works
You've already seen how federated identity works within a single realm. Indeed, Figure 2 is a small example of identity federation between your application and a local issuer in your realm. That relationship doesn't change when your issuer federates
with an issuer in a different realm. The only change is that your issuer is now configured to accept a security token issued by a partner company instead of directly authenticating users from that company. Your issuer trusts another issuer to authenticate
users so it doesn't have to. This is similar to how your application trusts its issuer.
Figure 10 shows the steps for federating identity across realms.
Federating identity across realms
This is exactly the same as what you've already seen in the first illustration in this chapter, with the addition of an initial handshake in the partner's realm. Users first authenticate with an issuer in their
own realm. They present the tokens they receive from their exchanges to your issuer, which accepts it in lieu of authenticating them directly. Your issuer can now issue a token for your application to use. This token is what the user sends to your application.
(Of course, users know nothing about this protocol—it's actually the browser or smart client that does this on their behalf). Remember, your application will only accept tokens signed by the one issuer that it trusts. Remote users won't get access
if they try to send a token from their local issuer to your application.
At this point, you may be thinking, "Why should my company trust some other company to authenticate people that use my application? That doesn't seem safe!" Think about how this works
claims-based identity. Executives from both companies meet and sign legal contracts. Then the IT staff from the partner company contacts your IT staff and specifies which of their users need accounts provisioned and which roles they will need.
The legal contracts help ensure that nobody abuses the trust that's been established. This process has been working for years and is an accepted practice.
Another question is why should you bother provisioning accounts for those remote users when you know that data will get stale over time? All that claims-based identity does is help you
automate the trust
, so that you get fresh information each time a user visits your application. If Alice quits, the IT staff at her company has great personal incentive to disable her account quickly. They don't want a potentially disgruntled employee
to have access to company resources. That means that Alice won't be able to authenticate with their issuer anymore, which means she won't be able to use your application, either. Notice that nobody needed to call you up to tell you about Alice. By
decentralizing identity management, you get better information (authoritative information, you could say) about remote users in a timely fashion.
One possible drawback of federating identity with many other companies is that your issuer becomes a single point of failure for all of your federation relationships. Issuers should be as tightly guarded as domain controllers. Adding features is never without
risk, but the rewards can lead to lower costs, better security, simpler applications, and happier users.
The issuer's job is to take some generic incoming identity (perhaps from a Kerberos ticket or an X.509 certificate) and transform it into a security token that your application can use. That security token is like the boarding pass, in that it contains
all of the user's identity details that your application needs to do its job, and nothing more. Perhaps instead of the user's Windows groups, your boarding pass contains roles that you can use right away.
On the other end of the protocol are users who can use their single sign-on credentials to access many applications because the issuer in their realm knows how to authenticate them. Their local issuer provides claims to applications in their local realm as
well as to issuers in other realms so that they can use many applications, both local and remote, without having to remember special credentials for each one.
Consider the application's local issuer in the last illustration, "Federating identity across realms." It receives a security token from a user in some other realm. Its first job is to reject the request if the incoming token wasn't issued
by one of the select issuers that it trusts. But once that check is out of the way, its job now becomes one of
. It must transform the claims made by the remote issuer into claims that make sense for your application. For a practical example, see chapter 4, "Federated Identity for Web Applications."
In ADFS, this sort of transformation is done with rules such as, "If you see a claim of this type, with this value, issue this claim instead." For example, your application may have a role called Managers that grants special access to manager-specific
features. That claim may map directly onto a Managers group in your realm, so that local users who are in the Managers group always get the Managers role in your application. In the partner's realm, they may have a group called Supervisors that needs to
access the manager-specific features in your application. The transformation from Supervisors to Managers can happen in their issuer; if it does not, it must happen in yours. This transformation simply requires another rule in ADFS. The point is that issuers
such as ADFS are specifically designed to support this type of transformation, because it's rare that two companies will use exactly the same vocabulary.
Home Realm Discovery
Now that you've seen the possibility of cross-realm federation, think about how it works with browser-based applications. Here are the steps:
- Alice (in a remote realm) clicks a link to your application.
- You redirect Alice to your local issuer, just like before.
- Your issuer redirects Alice's browser to the issuer in her realm.
- Alice's local issuer authenticates and issues a token, sending Alice's browser back to your issuer with that token.
- Your issuer validates the token, transforms the claims, and issues a token for your application to use.
- Your issuer sends Alice's browser back to your application, with the token that contains the claims your application needs.The mystery here is in step 3. How does the issuer know that Alice is from a remote realm? What prevents the issuer from thinking
she's a local user and trying to authenticate her directly, which will only fail and frustrate the user? Even if the issuer knew that Alice was from a remote realm, how would it know which realm it was? This is because it's likely that you'll have
more than one partner.
This problem is known as "home realm discovery." Your issuer has to determine if Alice is from the local realm or if she's from some partner organization. If she's local, the issuer can authenticate her directly. If she's remote, the issuer
needs to know a URL to redirect her to so that she can be authenticated by her home realm's issuer.
There are two ways to solve this problem. The simplest one is to have the user help out. In step 2, when Alice's browser is redirected to your local ADFS, it pauses the protocol and displays a Web page to Alice, asking her what company she works for. (Note
that it doesn't help Alice to lie about this, because her credentials are only good for one of the companies on the list—her company.) Alice clicks the link for her company and the protocol continues, since the issuer now knows what to do. To avoid asking
Alice this question in the future, your issuer sets a cookie in her browser so that next time it'll know who her issuer is without having to ask.
The second way to solve this problem is by adding a hint to the query string that's in the link that Alice clicks in step 1. That query string will contain a parameter named
stands for home realm).
The issuer (ADFS 2.0) looks for this hint and automatically maps it to the URL of the user's home realm. This means that the issuer doesn't have to ask Alice who her issuer is because the application relays that information to the issuer. The issuer
uses a cookie, just as before, to ensure that Alice is never bothered with this question.
Home Realm Discovery and Web Services
Using a Web page to get the user's help may make sense for Web applications. They are interactive by nature and the browser can display a home realm discovery page if needed. But how do you solve this problem with smart clients and Web services? This is
where information cards can help (note that information cards are beyond the scope of this guide).
Design Considerations for Claims-Based Applications
Admittedly, it's difficult to offer general prescriptive guidance for designing claims because they are so dependent on the particular application. This section poses a series of questions and offers some approaches to consider as you look at your options.
What Makes a Good Claim?
Like many of the most important design decisions, this question doesn't always have a clear answer. What's important is that you understand the tensions at play and the tradeoffs you're facing. Here are some concrete examples that might help you
start thinking about some general criteria for what makes a good claim.
First, consider a user's e-mail address. That's a prime candidate for a claim in almost any system, because it's generally very tightly coupled to the user's identity, and it's something that everyone needs if you decide to federate identity
across realms. An e-mail name can help you personalize your system for the user in a very meaningful way.
What about a user's choice of a skin or theme for your Web site? Certainly, this is "personalization" data, but it's also data that's particular to a single application, and it's hard to argue that this is part of a user's identity.
Your application should manage this locally.
What about a user's permission to access data in your application? While it may make sense in some systems to model permissions as claims, it's easy to end up with an overwhelming number of these claims as you model finer and finer levels of authorization.
A better approach is to define a boundary that separates the authorization data you'll get from claims from the data you'll handle through other means. For example, in cross-realm federation scenarios, it can be beneficial to allow other realms to
be authoritative for some high-level roles. Your application can then map those roles onto fine-grained permissions with tools such as Windows Authorization Manager (AzMan). But unless you've got an issuer that's specifically designed for managing
fine-grained permissions, it's probably best to keep your claims at a much higher level.
Before making any attribute into a claim, ask yourself the following questions:
- Is this data a core part of how I model user identity?
- Is the issuer an authority on this information?
- Will this data be used by more than one application?
- Do I want an issuer to manage this data or should my application manage it directly?
How Can You Uniquely Identify One User From Another?
Because each person isn't born with a unique identifier (indeed, most people treasure their privacy), this has always been, and will likely always be a tricky problem. Claims don't make this any easier. Fortunately, not all applications need to know
exactly who the user is. Simply being able to identify one returning user from another is enough to implement a shopping cart, for example. Many applications don't even need to go this far. But other applications have per-user state that they need to track,
so they require a unique identifier for each user.
Traditional applications typically rely on a user's sign-in name to distinguish one user from the next. So what happens when you start building claims-based applications and you give up control over authentication? You'll need to pick one (or a combination
of multiple) claims to uniquely identify your user, and you'll need to rely on your issuer to give you the same values for each of those claims every time that user visits your application. It might make sense to ask the issuer to give you a claim that
represents a unique identifier for the user. This can be tricky in a cross-realm federation scenario, where more than one issuer is involved. In these more complicated scenarios, it helps to remember that each issuer has a URI that identifies it and that can
be used to scope any identifier that it issues for a user. An example of such a URI is http://issuer.fabrikam.com/unique-user-id-assigned-from-fabrikams-realm.
E-mail addresses have convenient properties of uniqueness and scope already built in, so you might choose to use an e-mail claim as a unique identifier for the user. If you do, you'll need to plan ahead if you want users to be able to change the e-mail
addresses associated with their data. You'll also need a way to associate a new e-mail address with that data.
How Can You Get a List of All Possible Users and All Possible Claims?
One thing that's important to keep in mind when you build a claims-based application is that you're never going to know about all the users that could use your application. You've given up that control in exchange for less responsibility, worry,
and hassle over programming against any one particular user store. Users just appear at your doorstep, presenting the token they got from the issuer that you trust. That token gives you information about who they are and what they can do. In addition, tokens
that contain the necessary claims should be rejected, even if they come from a trusted source. If you've designed things properly, you're not going to have to change your code to support new users, even if those users come from other realms, as they
do in federation scenarios.
So how can you build a list of users that allows administrators to choose which users have permission to access your application and which don't? The answer is, "Find another way!" This is a perfect example of where an issuer should be involved
with authorization decisions. The issuer shouldn't issue tokens to users who aren't privileged enough to use your application. It should be configured to do this without you having to do anything at all in your application.
When designing a claims-based application, always keep in mind that a certain amount of responsibility for identity has been lifted from your shoulders as an application developer. If an identity-related task feels hard or impossible to build into your application
logic, consider whether it's possible for your issuer to handle that task for you.
Where Should Claims Be Issued?
This question is a moot point when you have a simple system with only one issuer. But when you have more complicated systems where multiple issuers are chained into a path of trust that leads from the application back to the issuer in the user's home realm,
this question becomes very relevant.
The short answer to the question is: "Use the issuer that knows best."
Take, for example, a claim such as a person's e-mail name. The e-mail name of a user isn't going to change depending on which application he or she uses. It makes sense for this type of claim to be issued close to the user's home realm. Indeed,
it's most likely that the first issuer in the chain, which is the identity provider, would be authoritative for the user's e-mail name. This means that downstream issuers and applications can benefit from that central claim. If the e-mail name is ever
updated, it only needs to be updated at that central location.
Now think about an "action" claim, which is specific to an application. An application for expense reporting might want to allow or disallow actions such as
. Another type of application, such as one that tracks bugs, would have very different actions, such as
. In some systems, you might find that it works best to have the individual applications handle these applications internally, based on higher-level claims such as roles or groups. But if you do decide to factor these actions
out into claims, it would be best to have an issuer close to the application be authoritative for them. Having local authority over these sorts of claims means you can more quickly implement policy changes without having to contact some central authority.
What about a group claim or a role claim? In traditional RBAC (Role-Based Access Control) systems, a user is assigned to one or more groups, the groups are mapped to roles, and roles are mapped to actions. There are many reasons why this is good: the mapping
from roles to actions for an application can be done by someone who is familiar with it and who understands the actions defined for that application. For example, the mapping from user to groups can be done by a central administrator who knows the semantics
of each group. Also, while groups can be managed in a central store, roles and actions can be more decentralized and handled by the various departments and product groups that define them. This allows for a much more agile system where identity and authorization
data can be centralized or decentralized as needed.
Issuers are typically placed at boundaries in organizations. Take, for example, a company with several departments. Each department might have its own issuer, while the company has a central issuer that acts as a gateway for claims that enter or leave it. If
a user at this company accesses an application in another, similarly structured company, the request will end up being processed by four issuers:
- The departmental issuer, which authenticates the user and supplies an e-mail name and some initial group claims
- The company's central issuer, which adds more groups and some roles based on those groups
- The application's central issuer, which maps roles from the user's company to roles that the application's company understands (this issuer may also add additional role-claims based on the ones already present)
- The application's departmental issuer, which maps roles onto actions
You can see that as the request crosses each of these boundaries, the issuers there enrich and filter the user's security context by issuing claims that make sense for the target context, based on its requirements and the privacy policies. Is the e-mail
name passed all the way through to the application? That depends on whether the user's company trusts the application's company with that information, and whether the application's company thinks the application needs to know that information.