点此显示原文 点此隐藏原文

While the “Geneva” Server adds quite a bit to its predecessor AD FS, including a full-fledged STS, it also supports all of the functions of its earlier incarnation. For example, as mentioned earlier, the “Geneva” Server allows using WS-Federation to provide identity federation for passive clients (i.e., Web browsers). Unlike AD FS, however, the “Geneva” Server also supports using the SAML 2.0 protocol for this purpose, as mentioned earlier. Supporting this alternative protocol, which has been embraced by the Liberty Alliance and others, allows Windows systems with the “Geneva” Server to work with a broader range of identity federation products.

点此显示原文 点此隐藏原文

Also like AD FS, the “Geneva” Server allows an administrator to establish trust with other STSs. Figure 13 illustrates the fundamentals of how this works.

点此显示原文 点此隐藏原文

Figure 13: Establishing a trust relationship between STSs requires exchanging certificates and more.

点此显示原文 点此隐藏原文

The situation shown here is identical to the one shown earlier in Figure 11: The application in enterprise Y only trusts tokens issued by its own STS. This means that a client in enterprise X must first get a token from its own STS, then use this to request a new token from the STS in enterprise Y, as described earlier. Accomplishing this requires addressing several issues.

点此显示原文 点此隐藏原文

For example, how does the STS in enterprise Y, called the federation provider, know that the token this client sends was actually issued by the STS in enterprise X, referred to as the identity provider? The answer is that this token is signed by the identity provider using its private signing key. To allow the federation provider to verify this signature, the identity provider sends it a certificate containing the corresponding public key for this signing key, as Figure 13 shows. Also, the federation provider is able to transform tokens it receives based on a transformation policy defined by its administrator. To define this policy, the federation provider must have a list of every possible claim type that the identity provider might send to it. As Figure 13 shows, the identity provider sends the federation provider a list of the claim types it can expect to receive.

点此显示原文 点此隐藏原文

Here’s another problem: When the identity provider creates a token that’s destined for the federation provider, it can encrypt this token so attackers can’t read it. To allow this, the federation provider sends a certificate for its encryption key to the identity provider, as Figure 13 shows. The identity provider uses the public key in this certificate to encrypt all tokens it sends to this federation provider, ensuring that only the federation provider’s STS can read them.

点此显示原文 点此隐藏原文

AD FS required similar exchanges to establish trust between federated domains. The “Geneva” Server makes this process simpler by automating what were entirely manual processes in AD FS. For example, when a certificate is about to expire, the “Geneva” Server can automatically create a new key pair and certificate, then send the certificate to its partner STS.

点此显示原文 点此隐藏原文

Another advance that the “Geneva” Server provides over AD FS is broader support for storing identity information. Unlike its predecessor, the “Geneva” Server views its account store, containing things like usernames and passwords, separately from its attribute store, which holds other information about users. For the account store, the “Geneva” Server supports either AD DS or AD LDS. For the attribute store, Microsoft plans to allow a range of options in the final release, including AD DS, AD LDS, SQL Server, and others (although not all of these are available in the first beta release).

点此显示原文 点此隐藏原文

CardSpace “Geneva” is the second version of Microsoft’s CardSpace technology. The basics are the same as in the original, with enhancements that reflect what CardSpace’s designers have learned since its first release. This section takes a deeper look at how this technology works, including some of the most important changes in CardSpace “Geneva”.

点此显示原文 点此隐藏原文

To a user, CardSpace “Geneva” represents each available identity as a card, as shown earlier in Figure 6. When a user selects a card, CardSpace “Geneva” requests a token from an STS at the corresponding identity provider. But how is the connection made between the card seen by a user and this STS? The answer is that each association between a card and an identity provided by some STS is represented by an information card. Figure 14 shows how this looks.

点此显示原文 点此隐藏原文

An information card is just an XML file, and as the figure shows, each one represents a relationship with an identity provider. This relationship lets the user get tokens from the identity provider for use with applications willing to accept these tokens. The information card contains everything needed to find the right STS at the right identity provider, then request a token for the identity this card represents. The card doesn’t contain any claims, however; these are all maintained by the identity provider. The sole purpose of the information card is to store the information needed to find the right STS and request a token for a particular identity.

点此显示原文 点此隐藏原文

The terminology can get confusing, so here’s a quick recap: A user selects a card (a visual representation) that’s associated with an information card (an XML file) that contains all of the information needed to request a token (a signed group of bytes issued by an STS). Don’t confuse information cards with tokens—they’re not the same thing.

点此显示原文 点此隐藏原文

Next question: Since every identity a user has is represented by an information card stored on the user’s machine, how do the information cards get there? The answer is that it’s up to the STS. Information cards don’t contain confidential information—they don’t hold a password the user supplies to authenticate token requests to the STS, for instance—so the problem isn’t too challenging. The “Geneva” Server can install an information card on a user’s machine in various ways, as can STSs from other vendors, such as IBM’s Tivoli Federated Identity Manager. Similarly, other identity selectors that support information cards, such as the open source Higgins selector, can accept cards provided by the “Geneva” Server and other STSs.

点此显示原文 点此隐藏原文

Another challenge for information card-based identity is supporting roaming users. Many of us use a desktop computer at work, another one at home, and a laptop while we’re traveling, yet we’d like to present the same digital identity from all of them. To allow a user to roam among these different machines, CardSpace provides a card export feature. This option allows copying information cards onto an external storage medium, such as a USB key. The cards can then be installed onto other machines, letting a user request security tokens from identity providers in the same way whether he’s using his home computer, his office computer, or his laptop in a hotel room. To guard against attacks, exported information cards are encrypted using a key derived from a user-selected pass-phrase. This ensures that even if the storage medium is lost, only someone who knows the pass-phrase can decrypt the cards it contains. Microsoft is also investigating the possibility of letting a user store information cards on an Internet-accessible server, i.e., in the cloud. On a machine you control, CardSpace “Geneva” could then connect invisibly to these cloud-based information cards, using them to request tokens. This would make it easier to share identities among the small set of machines that each of us use regularly.

点此显示原文 点此隐藏原文

Yet another issue that CardSpace “Geneva” must address is revocation. Once an identity provider has issued an information card to a user, how can that card be revoked? In the simplest case, the identity provider itself might wish to stop issuing security tokens based on this card. Perhaps using this identity provider requires a paid subscription, for example, and the user hasn’t kept up his payments. Revocation in this case is simple: the identity provider just stops honoring requests for security tokens made with this card. Every request carries a unique CardSpace reference, so it’s easy for the identity provider to identify requests made with cards it has revoked.

点此显示原文 点此隐藏原文

A slightly more complex case is when the user wishes to revoke an information card. Perhaps an attacker has stolen the user’s laptop containing information cards issued by various identity providers. To address this problem, each information card can be assigned a PIN that must be entered each time the card is used. If this is done, an attacker can’t use the stolen cards (and thus the identities they correspond to) unless he knows the PIN for each one. Also, recall that using a card issued by an external identity provider typically requires the user to authenticate himself, such as by entering a password. Since this authentication information isn’t contained in the card itself, an attacker can’t use these stolen cards to impersonate the user.

点此显示原文 点此隐藏原文

A slightly more complex case is when the user wishes to revoke an information card. Perhaps an attacker has stolen the user’s laptop containing information cards issued by various identity providers. To address this problem, each information card can be assigned a PIN that must be entered each time the card is used. If this is done, an attacker can’t use the stolen cards (and thus the identities they correspond to) unless he knows the PIN for each one. Also, recall that using a card issued by an external identity provider typically requires the user to authenticate himself, such as by entering a password. Since this authentication information isn’t contained in the card itself, an attacker can’t use these stolen cards to impersonate the user.

点此显示原文 点此隐藏原文

Figure 15: A Web page can display this icon to indicate that it accepts information card-based logins

点此显示原文 点此隐藏原文

In the examples described so far, an identity provider and the STS it provides have always been external to the user’s machine. There’s no reason why this has to be true, however. Why can’t the user act as her own identity provider, requesting tokens from an STS installed on her own machine? The answer is that, by using the self-issued identity provider that’s part of CardSpace “Geneva”, she can. Figure 16 illustrates this idea.

点此显示原文 点此隐藏原文

Figure 16: The self-issued identity provider allows a user to act as her own identity provider.

点此显示原文 点此隐藏原文

Using the self-issued identity provider changes a number of things, such as how much trust an application can place in the claims this provider issues, but the mechanics remain much the same. As the figure shows, the self-issued identity provider, complete with an STS, runs on the user’s computer. As with any other identity provider, the user can install an information card that’s associated with an identity this provider maintains. When the user selects the card associated with this identity, the CardSpace “Geneva” identity selector requests a SAML token from the local self-issued identity provider, then sends that token to whatever application the user is accessing. The claims in this token are fixed—users can’t add to them—and they include basic information such as the user’s name.

点此显示原文 点此隐藏原文

Yet there’s an obvious question here: What good are these tokens? When an application gets a token issued by an external identity provider, it can have some faith in the claims that token contains (assuming it trusts the identity provider, of course). But how can an application ever trust claims that come from an identity provider owned by the user herself?

点此显示原文 点此隐藏原文

To understand when self-issued identities can be useful, think about how usernames and passwords are commonly used on the Internet today. When you access a new site, you’re typically asked to create a username and password, which are then stored by that site. The next time you access the site, you provide the same username and password, allowing the site to recognize you. But does the site really know who you are? Of course not. Choosing the username “Angelina Jolie” doesn’t mean that you’re in fact a famous movie star. The real purpose of a username and password isn’t to establish your true identity. It’s to allow the site to recognize you as the same user each time, proving the continuity of the relationship.

点此显示原文 点此隐藏原文

A token created by a self-issued identity provider can be used in the same way. While an application that accepts these tokens can’t put much faith in the claims this token contains (just as with a self-chosen username), it can recognize you as the same user over and over. For many applications, including pretty much every Web site that relies on usernames and passwords today, this is all that’s needed.

点此显示原文 点此隐藏原文

But why bother? How is a token issued by a CardSpace “Geneva” self-issued identity provider better than a simple username and password? Unless there are some advantages over what we do today, there’s no reason to switch. These tokens can have significant benefits, however, including the following:

点此显示原文 点此隐藏原文

In the lexicon of claims-based identity, an information card issued by a self-issued provider is known as a personal card, while one issued by an external identity provider is called a managed card. And just as an application can indicate which external identity providers it will accept tokens from, it can also indicate whether it accepts tokens from self-issued providers. (One more point worth making here: The self-issued provider isn’t included in the first beta release of CardSpace “Geneva”.)

点此显示原文 点此隐藏原文

In the lexicon of claims-based identity, an information card issued by a self-issued provider is known as a personal card, while one issued by an external identity provider is called a managed card. And just as an application can indicate which external identity providers it will accept tokens from, it can also indicate whether it accepts tokens from self-issued providers. (One more point worth making here: The self-issued provider isn’t included in the first beta release of CardSpace “Geneva”.)

点此显示原文 点此隐藏原文

An STS provides tokens containing identity information, while an identity selector helps users choose which tokens they’d like to use. Yet both are pointless unless applications are modified to accept and use these tokens. The goal of the “Geneva” Framework is to make it easier to do this, helping developers create claims-aware applications.

点此显示原文 点此隐藏原文

As described earlier, for example, the “Geneva” Framework provides built-support for verifying a token’s signature and extracting its claims. Each claim is extracted into an instance of the “Geneva” Framework-defined Claim class, providing a consistent way for developers to work with a token’s information. This class’s properties include things such as:

点此显示原文 点此隐藏原文

Along with helping developers create claims-aware applications, the “Geneva” Framework also provides support for creating a custom STS. Even though a primary goal of “Geneva” Server is to reduce the need to hand roll your own STS, there are situations where building an STS can make sense. For example, an ISV might use the “Geneva” Framework to create a custom STS for its own purposes.

点此显示原文 点此隐藏原文

There’s a lot more in the “Geneva” Framework, and creators of claims-aware Windows applications will need to become familiar with this library. For a more detailed look at this technology and how to use it, see Keith Brown’s white paper, available at https://connect.microsoft.com/Downloads/DownloadDetails.aspx?SiteID=642&DownloadID=12901.

点此显示原文 点此隐藏原文

Changing how people and applications work with identity is not a small thing. Given this, widespread adoption of claims-based identity is likely to take some time. Still, the foundation is now in place to make this much-improved approach real.

点此显示原文 点此隐藏原文

With the advent of “Geneva” Server, CardSpace “Geneva”, and the “Geneva” Framework, all of the pieces required to use claims-based identity on Windows are here. While this style of working with identity is far from a Microsoft-only initiative, making these components widely available for Windows is bound to make it more popular. For anyone who cares about improving the way we use identity in the digital world, this is certainly a step forward.

点此显示原文 点此隐藏原文

David Chappell is Principal of Chappell & Associates (www.davidchappell.com) in San Francisco, California. Through his speaking, writing, and consulting, he helps people around the world understand, use, and make better decisions about new technology.