The Identity Metasystem


So we need an identity metasystem. What does it look like? Well, it has to obey the laws of identity, expose the strengths of its constituent identity systems, provide interoperability between them, and enable the creation of a consistent and straightforward user interface over all of them.

Just to emphasize the point, it should be completely open and nonproprietary: It is "the identity metasystem" not "the Microsoft or IBM or whoever identity metasystem."

There are three roles in the metasystem:

  • Subjects, the entities about whom claims are made

  • Identity Providers (IPs), which issue digital identities

  • Relying Parties (RPs), which require digital identities

To give but one example to illustrate the roles, when I buy a book online I am the subject, my bank is the identity provider giving my credit-card details, and the online bookstore is the relying party consuming those details to enable me to buy a copy of The Idiot's Guide to PKI.

If you remember, our identity is packaged in a security token containing claims made by an identity provider. In the preceding example the online bookstore might specify that it requires a token that contains my name, address, and credit-card claims. I can then ask my bank to provide the required security token with proof that it was issued by them and a way to prove I am the rightful possessor of the token. When I give this token to the online bookstore, they verify that it came from my bank, and that I am the rightful purchaser, and they extract the claims and complete the transaction.

Notice here that the user is at the center. Potentially the token could have gone directly from bank to bookstorefrom identity provider to relying partybut instead it goes via the user so that she has control and consent over the release of identity information.

Expanding a little on the example, you can see a number of requirements for the system to work.

First, the relying party needs a way to specify the claims it requires in a way that everyone understands: "I need first name, surname, and address claims." Likewise, the identity provider needs a way to specify the claims it is able to supply.

Second, the relying party and the identity provider may use completely different identity systems with different token formatsthis is a metasystem, remember! So both parties need a technology-agnostic way to express the kinds of security tokens that they understand: "I need a SAML 1.1 or SAML 2.0 security token."

Furthermore, it would be useful if the identity provider and relying party could negotiate the types of claims they can use: "I can provide tokens of these types: X, Y"; " I can receive tokens of these types: Y, Z""Okay, let's use token type Y because we both understand that."

This is a bit like people communicating via languages and raises an interesting idea. If I speak English and French but you speak only Japanese, Swedish, and German, we can still communicate provided we can find someone who can understand, say, French and Japanese. Provided we trust that person not to make things up or fall victim to Chinese Whispers (as in the game of Telephone), we can interoperate perfectly well.

Within the context of our identity system, we may need to translate not only the type of token but also the claims themselves. For example, my identity provider may provide a "date of birth" claim, but the relying party may require an "older than 21" claim. Or my company may provide an "is at job level 1000" claim, but the relying party needs an "is a manager" or "is an executive" claim.

What we need is a token translation service: a trusted service that can receive tokens of one type and convert them to tokens of another type. Such beasts exist and they are commonly known as security token services (or STSs).

Furthermore, the user cannot "just" ask an identity provider for a security tokenthat's not very secure! The user has to authenticate to the identity provider in some way and prove who she is. Put another way, the user must supply some kind of security token (asserting her identity) in order to get a security token back (also asserting her identity) that she can give to the relying party.

Thus it becomes clear that

  • Identity providers are security token services.

  • All interactions with security token services involve giving one kind of security token and getting another one back.

Meanwhile, at the center of everything lies the user. Regardless of the complex flow of claims, tokens, and token types between the different systems within the metasystem, we want the user to have a simple, consistent experience and be able to control the release of information.

These requirements can be summarized as stated here:

  • Negotiation Way to enable relying party, subject, and identity provider to negotiate technical policy requirements

  • Encapsulation Technology-agnostic way to exchange policies and claims between identity provider and relying party.

  • Claims transformation Trusted way to change one set of claims regardless of token format into another.

  • User experience Consistent user interface across multiple systems and technologies.

The architecture that enables the identity metasystem to be implementedallowing us to meet the preceding requirements and link together identity providers, subjects, and relying partiesis the WS-* Web Services architecture (http://msdn.microsoft.com/webservices/). This set of open specifications is available for anyone to use on a reasonable and nondiscriminatory basis and has been adopted across the industry. For our purposes, the key specifications for the metasystem are WS-SecurityPolicy, WS-MetadataExchange (WS-MEX), and WS-Trust.

WS-SecurityPolicy allows us to describe the security token and claim requirements of a service in policy, and WS-MetadataExchange allows us to query and retrieve these service policies. WS-Trust defines the mechanism for requesting and receiving security tokens. In other words, it defines how a security token service communicates to the world. As you have seen, this is very simple: There is a Request for a Security Token (RST) and a subsequent Request for a Security Token Response (RSTR). Figure 14.1 helps show how everything fits together.

Figure 14.1. Identity metasystem architecture.


There are multiple relying parties, each with different token and claim requirements expressed using WS-SecurityPolicy. If we want to access one of these relying parties, we can find out their policy using WS-MEX. After we know their requirements, we can select a matching identity provider (or chain of providers).

For example, a relying party may require SAML 1.1 tokens containing my name and SSN from "any" identity provider. I can then select one of the identity providers that is able to provide the right token for the job.

The identity selector in the diagram is the "consistent user experience" part of the metasystem. After being invoked by an application, the identity selector performs the negotiation between the relying party and identity provider(s), displays the matching identity providers and relying parties to the subject, allows the user to select appropriately, obtains a security token containing the requested claims, and releases it to the requestorall under the supervision of the subject (that is, the user).

Furthermore, the identity selector should be agnostic to specific security token types and identity mechanisms. You could use the most esoteric security token imaginable and the identity selector will just pass it on. It is a conduit for identity flow under user control between identity providers and relying parties.




Presenting Microsoft Communication Foundation. Hands-on.
Microsoft Windows Communication Foundation: Hands-on
ISBN: 0672328771
EAN: 2147483647
Year: 2006
Pages: 132

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net