Applies to:
Windows CardSpace
Windows
Windows XP
Windows Server 2003
Summary: This article introduces the set of new Windows capabilities code-named CardSpace, which provides a standards-based solution for working with and managing diverse digital identities. (25 printed pages)
Understanding Digital Identity
Who are you? It's a simple question, but it doesn't have a simple answer. The way you represent your identity changes as you move through the world. When you present your passport at an airport's Immigration Desk, you're a citizen of some country. When you show your driver's license to a policeman who's stopped you for speeding, you're a legal driver who resides in some locality. When you use your credit card to pay for a best-selling novel at a bookstore, you're a customer with a particular account number. Different contexts require different identities, each of which is expressed in a different way and provides different information.
All of these contexts have well-understood ways for you to establish your identity. Yet, in one very important context—the networked world—identity is currently a much more muddled thing. Just as in the physical world, all of us have a variety of digital identities, and they're expressed in different ways. Today, however, there's no consistent way to deal with this portfolio of digital identities. Instead, we're left struggling in a complex, confusing, and insecure environment.
Yet different kinds of digital identities will always be necessary—no single identity will suffice. And the reality is that these identities will always be provided by a range of different sources—no single identity provider will suffice, either. This means that the solution is not to mandate a single system for digital identity, but rather to find a coherent way to use multiple digital identity systems. What's required is a system of systems—a metasystem—focused on identity.
Making this identity metasystem a reality requires cooperation. No single organization can unilaterally impose a solution. Fortunately, vendor-neutral communication standards exist that can be used to address this issue. Based on SOAP and XML, these standards include WS-Security, WS-Trust, WS-MetadataExchange, and WS-SecurityPolicy. Using these Web services technologies, it's possible to define a consistent way to work with any digital identity created by any source, using any identity technology.
Working with others, Microsoft has played a major role in defining this standards-based identity metasystem. Microsoft is also adding new capabilities to Windows to help make the identity metasystem a reality. Windows CardSpace, originally code-named "InfoCard," lets any Windows application, including Microsoft technologies such as the next release of Internet Explorer and those created by others, give its users a common way to work with digital identities. Part of the .NET Framework 3.0, CardSpace will be available for Windows Vista, Windows XP, and Windows Server 2003, and it’s scheduled to be released in early 2007.
Windows is a widely used operating system, and so Cardspace is an important part of making the identity metasystem real. Still, this solution can't succeed unless other organizations also implement it. Accordingly, Microsoft is actively encouraging the creation and use of software that can participate in the identity metasystem. The goal is to let people on any machine, running any operating system, use digital identities as easily, as effectively, and as securely as they today use their identities in the physical world.
Describing Digital Identity
Like identities in the real world, digital identities come in all shapes and sizes. Perhaps you have an e-mail account with Yahoo, for example, identified by an e-mail address. You might also have digital identities with various commercial organizations, such as Amazon or eBay, along with identities for sites such as MySpace.com. Each of these is typically identified by a username that you defined. At work, you might have a digital identity assigned to you by your employer, identified by your network login. This identity is probably maintained by some directory service, such as Active Directory, and today it's typically useful only within the boundaries of your company network.
Just as in the real world, there are good reasons to use different digital identities in different contexts. It's common, for instance, to associate different information with each identity. An identity that you use with Amazon might allow access to your credit card number, while one used with MySpace.com does not. The rules for getting each identity are also different. Getting a digital identity at Amazon is easy: just make up a username and password. Getting a digital identity at your employer is probably somewhat more difficult, since, at a minimum, it requires the approval of the administrators who run your company's network.
Representing Digital Identity: Security Tokens
Despite their diversity, digital identities all have one important thing in common: when transmitted on the network, every digital identity is represented by some kind of security token. A security token is just a set of bytes that expresses information about a digital identity. As shown in Figure 1, this information consists of one or more claims, each of which contains some part of the total information conveyed about this identity. A simple security token might include only a claim containing a username, while a more complex one might include claims containing a user's first name, last name, home address, and more. Security tokens for some digital identities might also include claims that contain sensitive information such as credit card numbers.
Figure 1. Security token
With most security tokens, some information is provided in order to prove that these claims really do belong to the user who's presenting them. One simple (and currently very common) way to do this is to send a password along with the claims. A more powerful approach is to digitally sign all or part of the claims by using a private key, and then provide the corresponding public key, perhaps wrapped in a certificate. However it's done, the security tokens that represent digital identities commonly provide some kind of proof that allows a receiver of the token to verify that this token really does represent the person or organization with that identity.
While the basic idea of every security token is the same—it's a collection of claims—a variety of different formats are used today to represent those tokens. The simplest example is just a username represented as a text string, but more complex formats such as X.509 certificates and Kerberos tickets are also common. None of these formats were designed to allow the conveyance of an arbitrary set of claims, however—something that's quite useful for some digital identities. Tokens created using the Security Assertion Markup Language (SAML), a standard created by the industry group OASIS, do allow this. Based on XML, SAML can be used to define security tokens that contain any required set of claims.
Traditionally, digital identities have been used primarily for authentication. Today's most common security token formats—username, X.509 certificates, and Kerberos tickets—reflect this, because the information they carry is largely focused on authenticating an identity. But why shouldn't digital identities be as broadly useful as real identities? Every card in your wallet reflects some kind of identity, and each one also carries useful information that some authority asserts is true. For example, your driver's license includes your name, your age, perhaps your picture, and other information, all asserted to be correct by some governmental organization. A digital identity that expressed this information could be useful for various things, such as proving that you're 21 or older, or that you really do wear glasses. Similarly, each of your credit cards carries a card number and expiration date along with your name. Just as these cards are useful in the physical world, it would also be useful to create a digital identity for each card that could be used to generate a security token carrying the proper claims.
Even though security tokens have historically been focused on conveying just authentication information, it's important to realize that the notion of digital identity is broader than this. We don't typically use credit cards to authenticate ourselves, for example, but the information this identity conveys, such as the credit card number, is still valuable. In fact, the term security token is a misnomer, since tokens can carry information that has nothing to do with security. Using SAML or other approaches, it's possible to define security tokens that contain pretty much any desired information. Digital identities can now become as broadly useful in the networked world as are the many identities we use in the real world.
Using Digital Identity: Windows CardSpace and the Identity Metasystem
Life would be simpler if a single digital identity, represented with a single security token format, could be used for everything. Yet for the same reasons that we have different identities in the physical world, we will always have different identities in the digital world. The challenge is to create, use, and manage these diverse digital identities in an understandable and effective way.
This is exactly the problem that the identity metasystem addresses. Rather than invent yet another technology for creating and representing digital identities, the identity metasystem instead provides a consistent way to work with multiple digital identities, regardless of the kinds of security tokens they use. Using standard protocols that anyone can implement on any platform, the identity metasystem allows the acquisition and use of any kind of security tokens to convey identity.
By providing a way for users to select identities and more, Windows CardSpace plays an important part in the identity metasystem. This paper describes CardSpace and how it fits into the identity metasystem. The goal is to make clear what this technology offers and how it works. Be aware, however, that this description is based on a Beta release of the system. As always, some aspects might change before the technology's final release.
What Windows CardSpace Provides
Four aspects of this technology stand out as most important:
Support for any digital identity system
Consistent user control of digital identity
Replacement of password-based Web login
Improved user confidence in the identity of remote applications
This section describes how CardSpace, as part of the identity metasystem, provides each of these four things.
Support for Any Digital Identity System
The multiple digital identities that we use come from several different sources, and they are expressed in a variety of ways. In other words, we typically rely on a number of different digital identity systems, each of which may use a different underlying technology. To think about this diversity in a general way, it's useful to define three distinct roles:
User—Also known as the subject, the user is the entity that is associated with a digital identity. Users are often people, but organizations, applications, machines, and other things can also have digital identities.
Identity provider—An identity provider is just what the name suggests: something that provides a digital identity for a user. For the digital identity assigned to you by your employer, for example, the identity provider is typically a system such as Active Directory. For the digital identity you use with Amazon, the identity provider is effectively you, since you define your own username and password. Digital identities created by different identity providers can carry different information and provide different levels of assurance that the user really is who he claims to be.
Relying party—A relying party is an application that in some way relies on a digital identity. A relying party will frequently use an identity (that is, the information contained in the claims that make up this identity's security token) to authenticate a user, and then make an authorization decision, such as allowing this user to access some information. A relying party might also use the identity to get a credit card number, to verify that the same user is accessing it at different times, or for other purposes. Typical examples of relying parties include Internet websites such as online bookstore and auction sites, and any application that accepts requests through Web services.
Given these three roles, it isn't difficult to understand how Windows CardSpace and the identity metasystem can support any digital identity. Figure 2 shows the fundamental interactions among the three roles.
Figure 2. Interactions among the user, identity provider, and relying party roles
As Figure 2 suggests, a user might rely on an application that supports CardSpace, such as a Web browser, to access any of several relying parties. She might also be able to choose from a group of identity providers as the source of the digital identity she presents to those relying parties. Whatever choice she makes, the basic exchange among these parties has three steps:
1. First, the application gets the security token requirements of the relying party that the user wishes to access.
This information is contained in the relying party's policy, and it includes things such as what security token formats the relying party will accept, and exactly what claims those tokens must contain.
2. Once it has the details of the security token this relying party requires, the application passes this information to CardSpace, asking it to request a token from an appropriate identity provider.
3. Once this security token has been received, CardSpace gives it to the application, which passes it on to the relying party.
The relying party can then use this token to authenticate the user or for some other purpose.
This high-level view illustrates the most important aspects of the process. They include the following:
Windows CardSpace and the identity metasystem are entirely agnostic about the format of the security token that's requested from an identity provider and passed on to a relying party. In fact, CardSpace typically isn't even aware of what format this token is in. Because of this, CardSpace can work with any digital identity system, using any type of security token, including simple usernames, X.509 certificates, Kerberos tickets, SAML tokens, or anything else. This allows CardSpace and the identity metasystem to be used together with whatever digital identity technologies are in place. It also allows plugging in yet-to-be-created digital identity systems that might appear in the future.
All of the exchanges defined by the identity metasystem and implemented by CardSpace are done using open, published protocols.
In the most general scenario, a relying party's policy is described using WS-SecurityPolicy, that policy is retrieved using WS-MetadataExchange, a security token is acquired using WS-Trust, and that token is conveyed to the relying party using WS-Security (all if the WS-* protocols necessary to enable the secure exchange of identity tokens in the identity metasystem are (or soon will be) submitted to standards bodies.
In the simpler (and probably more common) scenario of a Web browser interacting with a website, the relying party's policy can be expressed using HTML, and both this policy information and the security token can be exchanged with the site using HTTPS. While interactions with an identity provider still depend on WS-Trust, a website isn't required to implement any of the WS-* specifications in order to act as a relying party.
In either scenario, working with CardSpace does not require relying parties or identity providers to implement any proprietary protocols.
As Figure 2 indicates, CardSpace is useful only if identity providers and relying parties implement the protocols used by the identity metasystem. While Microsoft has led the effort to define the metasystem, and it has created Windows CardSpace to provide key metasystem components for Windows, the effort cannot succeed without participation from other organizations.
Consistent User Control of Digital Identity
Having standard protocols for acquiring and transmitting security tokens is certainly useful. Yet without some way for users to understand and make sensible decisions about the digital identities these tokens represent, the system would collapse into useless complexity. Accordingly, one of the primary goals of CardSpace and the identity metasystem is to empower users—everybody from a security specialist, to your mom and dad—to make good decisions about using their digital identities.
To achieve this, CardSpace implements an intuitive user interface for working with digital identities. Figure 3 shows a representation of perhaps the most important part of this interface, the screen used to select an identity.
Figure 3. CardSpace identity selection screen
As this screenshot illustrates, each digital identity is displayed as an information card, sometimes shortened to just InfoCard (the source of this technology's codename). Each card represents a digital identity that the user can potentially present to a relying party. Along with the visual representation shown in the screenshot, each card also contains information about a particular digital identity. This information includes what identity provider to contact to acquire a security token for this identity, what kind of tokens this identity provider can issue, and exactly what claims these tokens can contain. (As described later, each information card is actually created by an identity provider, and then installed on a user's machine.) By selecting a particular card, the user is actually choosing to request a specific security token with a specific set of claims created by a specific identity provider. This technical complexity is hidden, however, leaving the user free to think in terms that make sense to him or her. Figure 4, a slightly expanded version of Figure 2, shows where the user's decision fits into the process.
Figure 4. Selecting an identity
As described earlier, the process begins with an application requesting a relying party's policy. Recall that this policy indicates what kind of security tokens this relying party can accept, and what claims those tokens must contain. Once this information is returned and passed to CardSpace, the system displays the card selection screen. To give the user a consistent experience, every information card he or she owns on this system is shown, just as every card in a wallet is visible when that wallet is opened. Only some cards are applicable in any situation, however, and therefore any information cards whose associated security token and claims don't match the requirements of this relying party are dimmed—that is, the user can't submit them. Once the user clicks on a particular card, CardSpace issues a request, as described earlier, to the identity provider associated with that card. As before, the identity provider then returns a security token that is passed on to the relying party.
Providing a consistent way for users to select digital identities is important for two main reasons:
Users have a consistent and predictable way to use their digital identities. Without this, for all but expert users, the result would surely be confusion and error. Every application built to use CardSpace will use the exact same mechanism for working with digital identities, presenting them to users through the exact same interface.
Users are shielded from differences in security technologies. You shouldn't care whether a particular identity's security token is expressed using X.509 certificates, SAML, or in some other way. By providing a common visual representation, CardSpace makes sure that users aren't faced with this unnecessary complexity. Everything is expressed in terms of what a user is concerned with: the identity itself and the information it contains.
For greater security, users can choose to protect individual information cards with personal identification numbers (PINs), requiring a user to enter this value before the information card is used. And to further deter local attacks, CardSpace creates a private Windows desktop for the identity selection screen that lets users choose a card. This is similar to the mechanism used to isolate the Windows login screen, and it prevents attacks by other locally-running processes.
It's worth pointing out that providing a consistent mechanism for users to select which digital identity to use is an intrinsic part of the identity metasystem. This paper focuses on CardSpace, a Windows technology, but implementations on other operating systems should provide their own intuitive screen for selecting a card.
Replacement of Password-Based Web Login
The most common kind of security token on the Internet today is just a username. The most common way to prove that a username is really yours is by providing the password associated with it. Sometimes the username and password are assigned to you by the site you're accessing, although more commonly you choose both yourself. Because sites that do this typically use SSL for communicating with your browser, this approach has been seen as reasonably secure. SSL ensures that the entire communication is encrypted, and therefore attackers can't steal your password by listening in on the communication.
Yet password-based schemes like this are vulnerable to another kind of attack: phishing. By sending deceptive e-mail messages, attackers attempt to trick users into logging in to spurious copies of real sites, revealing their passwords and perhaps other personal information. If passwords weren't the dominant authentication mechanism on the Web, however, this kind of phishing would be less of a threat—there would be no passwords to steal. To make this possible, and to improve the security of Web login in general, CardSpace allows replacing password-based Web login with a stronger mechanism.
Rather than authenticating users with passwords, a relying party such as a website might instead authenticate users with security tokens. For example, a company providing a family of websites might also offer an identity provider, running on some machine and accessible from any client, that is capable of issuing tokens that are accepted by all of the sites in that family. This approach minimizes the use of passwords, and it's certainly an option that can be used with CardSpace. Still, it's applicable only for a specific set of sites, since there's no single identity provider that all websites would accept in order to issue security tokens.
And what about the case where users choose their own usernames and passwords? This approach is very widely used by websites today, partly because it's simple: no third-party identity provider is required. It doesn't provide much assurance that the user really is who he or she claims to be, since the site can't know whether the name the user provides is really his or hers. But sites that use this approach typically only need to recognize a particular user each time he or she logs in. All this requires is a unique digital identity for that user, not necessarily one that contains any true information about him or her.
In a nutshell, the problem is this: a relying party would like to accept security tokens created by an identity provider, since doing so would allow replacing password-based logins that can be phished. In most cases, however, there's no widely accepted third-party identity provider to create these tokens. Yet since the goal is just to recognize multiple accesses by the same user, a complex digital identity isn't required.
To address this problem, CardSpace includes a self-issued identity provider. As Figure 5 shows, this self-issued identity provider runs on the local Windows system, and it can produce information cards just like any other identity provider. (In fact, to distinguish external identity providers from the self-issued variety, the external providers are sometimes referred to as managed identity providers, and the information cards they create are known as managed cards.) In the example shown in Figure 5, the user has three cards that were acquired from external identity providers, along with one card acquired from the self-issued identity provider.
Figure 5. User with an information card from a self-issued identity provider
Information cards created by the self-issued identity provider can contain only basic information, such as the user's name, postal address, e-mail address, and phone number. When a user chooses to submit one of these cards to a relying party, the self-issued identity provider on that user's system generates a SAML token containing the information the user has placed in this card. The self-issued identity provider also generates a public/private key pair, signing the security token with the private key. To prevent an attacker from reusing it, this token contains a timestamp and other information as well, making it useless to anyone except its original user. The application then sends this signed token, together with its associated public key, to the relying party. The relying party can use the public key to validate the security token's digital signature, thus ensuring that the token is being presented by its rightful owner. To make it impossible for relying parties to get together and track a user's activities by comparing that user's public key, the self-issued identity provider creates a different key pair for every relying party that's accessed with this card (although this detail is hidden from the user, who sees only a single information card for this identity).
The main idea is this: because the security tokens issued by most identity providers, including those created by CardSpace's self-issued identity provider, don't use passwords, relying parties, including websites and others, can use these tokens rather than passwords to authenticate their users. If a site doesn't use passwords, phishers can't trick users into revealing those passwords.
Phishing is a serious problem. If the only benefit of Windows CardSpace and the identity metasystem is to reduce this problem, they will have significantly improved today's online world.
Improved User Confidence in the Identity of Web Applications
Reducing the reliance of websites on password-based login will help reduce the pain of phishing, but it won't eliminate the problem. If a user is tricked into accessing the phisher's site, that site might accept any security token the user provided, self-issued or otherwise, and then ask for information such as a credit card number. The phisher wouldn't acquire the user's password for the site it's emulating, but he or she certainly might learn other useful things.
The root of the problem is the user's inability to distinguish the real site for, say, his or her bank, from an imposter site put up by a phisher. Both can display the same logos and other graphics. Both can even use SSL to secure the communication, since phishers can acquire certificates just like anybody else. If a user clicks on a link provided in a phisher's e-mail message, he may find himself connected to something that looks just like his bank's site. The little lock in the lower right corner of Internet Explorer might even be present, indicating that the communication is secured by SSL.
Fixing this problem requires two things:
A higher-assurance way for a website to prove its identity to users
A consistent way for those users to learn what level of assurance a site is offering as proof of its identity, and then to make an explicit decision about whether to trust that site.
Windows CardSpace and the identity metasystem address both of these issues.
Solving the first problem, improving how a website can prove its identity to users, depends on improving the certificates that are used to do this. Today, a website typically proves its identity with the certificate used for SSL communication. This is better than nothing, but SSL certificates actually prove only that a given site has a particular DNS name. There's no assurance that this DNS name corresponds to the information displayed on that site. A phisher might use a certificate issued for a DNS name that he owns, for example, to secure communication with a site that's been carefully crafted to look just like your bank. SSL certificates aren't enough to solve this problem.
To fix this, Microsoft is working with others in the industry to create a new level of certificate. This certificate can contain more information than a traditional SSL certificate, including the name, location, and logo of the organization it was issued to. This higher-assurance certificate will also be a more authoritative source of information because it's more difficult to get, requiring a stronger agreement with the authority that issues it. Both identity providers and relying parties can use this new certificate type to prove their identities to users of CardSpace applications.
Creating higher-assurance certificates addresses the first of the two issues listed above. Ultimately, however, a human being still needs to make a decision about which sites she trusts. CardSpace makes this decision explicit, requiring every user to approve the use of every identity provider and relying party that he or she wishes to access. When an information card is first installed on the user's system, a screen asks the user to verify that he or she is willing to accept security tokens created by the identity provider that issued this card. Similarly, the first time a relying party such as a website is accessed, a screen appears that requires the user to indicate his or her willingness to send it digital identity information. Figure 6 shows an example of how the screen displayed on a user's first access to a relying party might look:
Figure 6. Screen displayed the first time a relying partner is accessed
As this example shows, the screen can include the name, location, website URL, and logo of the organization whose identity is being approved (such as Overdue Media). It can also include the name and logo of the organization that has verified this information (such as VeriSign).
To help the user make good decisions, what's shown on the screen varies, depending on the kind of certificate provided by the identity provider or relying party. If the higher-assurance certificate described earlier is provided, the screen can indicate that the organization's name, location, website URL, and logo have been verified, as shown in Figure 6. This indicates to a user that this organization deserves more trust. If only an SSL certificate is provided, the screen would indicate that a lower level of trust is warranted. And, if an even weaker certificate, or no certificate at all, is provided, the screen would indicate that there's no evidence whatsoever that this site actually is who it claims to be. The goal is to help users make informed decisions about which identity providers they'll let provide them with digital identities, and which relying parties are allowed to receive those digital identities.
All of this raises a serious question: will this really help the average Windows user? Can somebody who's not knowledgeable about distributed security—someone who doesn't know what a certificate is, let alone which certificate authorities can be trusted—really make better decisions by using CardSpace? At the very least, providing a consistent and predictable experience for accessing new sites should help. Every application built on CardSpace, including the next release of Internet Explorer, will require the user's explicit approval to use each identity provider and relying party that he or she accesses with CardSpace. The user will always see the same screens for this, and those screens will provide guidance about how much assurance the user can have that the site is who it claims to be. Also, a user only makes a decision about trusting a site the first time that site is accessed. Later accesses, even months later, won't display a screen like the one shown in Figure 6. If this screen does appear when the user accesses what should be a previously-accessed site, it's a strong indication that he or she has somehow been tricked into accessing a phishing site.
Using Windows CardSpace: Example Scenarios
The clearest way to get a sense of how CardSpace and the identity metasystem might be used is to look at some typical examples. Think about what happens, for instance, when you access an online merchant such as an Internet bookstore. In the simplest case, no digital identity is involved—anybody can browse through the books on offer, without telling the merchant who they are. When you try to place an order, however, you need to log in, which requires providing a digital identity. Today, you'll most likely do this by entering a username and password, both of which you've chosen yourself. If this online merchant also supports CardSpace and the identity metasystem, it will provide another option for identifying yourself: using an information card. To allow this, the merchant might have a separate button on its login screen that you can click to log in with an information card, rather than entering your username and password.
Clicking this button causes the browser to use CardSpace to log in to this site. As usual, you'll be presented with the CardSpace selection screen, and you'll choose one of the cards in order to identify yourself to this merchant. It's likely (although not required) that the information card you choose in this case will be one created by the self-issued identity provider—that is, one that you created yourself. Since all the site needs to do at this point is identify you as a unique customer, this simple form of digital identity is sufficient. To pay for your purchases, you might enter your credit card information and mailing address on a Web form as usual.
In this simple scenario, CardSpace provided a way to log in to an online merchant without using a password. This is useful, and it's a step forward for digital identity on the Internet. Yet it's only the beginning of how digital identity can be used. In this example's payment step, for example, it might be possible to use an information card to send your credit card information to the site. Suppose that the company issuing your credit card offers an identity provider that allows you to request an information card corresponding to your physical card. Rather than entering the credit card information into a Web form, the site would alternatively offer a button on the payment screen that allows you to provide an information card. Clicking this button would result in your system displaying the CardSpace selection screen, letting you choose from all of the cards that will be accepted for payment at this site. Clicking on one of the cards would cause CardSpace to contact the identity provider of this card's issuer, get a security token containing your credit card information, and then present this to the online merchant.
As this example shows, digital identities aren't just for proving who you are. Like the physical identities represented by the various cards in your wallet, digital identities can be used to make payments, or for other purposes. For instance, suppose that the organization issuing driver's licenses in your locality made available an identity provider. You could now have a digital identity that allowed you to verify a variety of personal information to any relying party. In the
This driver's license identity provider could also provide other kinds of information cards. For example, some people might wish to have a way to prove that they're 21 or older, without revealing their name or other identifying information. A driver's license identity provider knows your age, and so along with an information card containing everything on your license, it might also offer a simpler card containing nothing more than your age. For people who qualified, this identity provider might even offer an information card that contained just an assertion that you are 21 or older, avoiding revealing something as potentially sensitive as your age. Even though they're called "digital identities," there's no requirement that they must contain any information at all that can actually be used to identify a particular user. For many uses, all that's needed is a way to assert a claim, such as being 21 or older, that's backed up by a trusted authority.
There are many more examples of how Windows CardSpace and the identity metasystem might be used. A provider of mobile phone service might offer an information card that its subscribers can use to charge online purchases to their phone bill. An employer might give its employees multiple digital identities, each with its own information card, for use on the company network. One identity could be used for normal access, while another, perhaps stripped of everything other than the fact that this person is an employee, might exist solely for the purpose of making anonymous suggestions to company management. Just as identities in the real world carry different information and are used for different purposes, digital identities can also be used in a variety of ways. The goal of CardSpace and the identity metasystem is to make this broad use possible.
Examining Information Cards
From the point of view of a user, an information card is the visual representation of a digital identity that he or she sees on his or her screen. To CardSpace, however, an information card is actually an XML document stored on the user's Windows machine. Given this, it's important to understand how cards are acquired, and what they contain. This section looks at these and other issues.
How Information Cards Are Acquired
Every information card is created by some identity provider. For the self-issued identity provider, CardSpace provides a graphical tool that lets users create cards. For other identity providers, which typically will run on other machines, a user must acquire the appropriate cards in some way, such as through the identity provider's website, or through an e-mail message sent by the identity provider. How this is done is defined by each identity provider—there's no mandated way to acquire information cards.
However it's acquired, each card (even one created by the self-issued identity provider) is digitally signed by the identity provider that issued it, and it comes with the identity provider's certificate. This signature is used to verify the identity of the identity provider itself. Once the card is on the user's machine, double-clicking it brings up a screen that allows the user to install this card into the standard CardSpace store. This is also when the user must approve the identity provider as a source for security tokens, as described earlier (although this approval isn't required for information cards created by the self-issued identity provider). Once the user has done this, the card can be used to request security tokens.
What Information Cards Contain
The contents of an information card help users intelligently choose a digital identity. They also allow CardSpace to match a card to a relying party's requirements, and to acquire an appropriate security token from the identity provider that issued this card. To accomplish these two goals, every information card contains the following:
A JPEG or GIF file with the image of the card that the user sees on his or her screen, along with the name of the card that's displayed to him or her.
One or more types of security tokens that can be requested from this identity provider, together with a list of claims each of those tokens can contain. This allows CardSpace to match a relying party's policy with the identity providers that can create security tokens meeting the relying party's requirements.
A URL for one or more endpoints at this identity provider that can be accessed to request a security token.
A URL identifying an endpoint at the identity provider from which its policy can be obtained. As described in the next section, this information also tells CardSpace how requests to the identity provider should be authenticated.
The date and time the information card was created.
A CardSpace reference for the card, which is a globally unique identifier specified as a URI. This identifier is created by the identity provider that issues the card, and it's passed back to that provider each time a security token is requested using this card.
It's also important to note what's not in an information card: sensitive data about this identity. For example, an information card created by a credit card company would not contain the user's credit card number. While this kind of sensitive information might appear as a claim in a security token created by an identity provider, it is always stored at the identity provider's system. When sent in a security token, this information is typically encrypted, making it inaccessible to both attackers and CardSpace. The key point is that sensitive information is never contained in an information card, and therefore it's never stored on the user's machine. If he or she chooses to, the owner of an information card can use CardSpace to preview the information that will appear in a security token created using that card. This information will be fetched from the identity provider that issued the card when the user asks to see it. Once it's been displayed, the sensitive information is then deleted from the user's system.
Roaming with Information Cards
People often want to present the same digital identity from multiple machines. Many of us use one computer at work, another at home, and a third while we're traveling. To allow roaming between these different machines, CardSpace provides a card export feature. This option allows the copying of 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.
Yet there are scenarios for which this solution isn't a good fit. Suppose someone wishes to use an CardSpace-based identity from an Internet café, for example. Doing this requires installing his or her information cards on the café's system. To use existing identities created using a self-managed identity provider, the keys associated with those identities would also need to be installed. Putting all of this information on a shared public computer is not a good idea. While the first release of CardSpace doesn't address this scenario, the ability to install a CardSpace store and a complete self-issued identity provider on USB-based hardware is planned for the near future. Once this option is available, a user will be able to plug this device into a computer, and then request security tokens directly from it, without installing information cards or keys on the machine being used.
Revoking Information Cards
Another issue that CardSpace 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, and the user hasn't kept up his or her 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, and therefore 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, which contains installed information cards issued by external identity providers. As mentioned earlier, 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 unless he or she also knows the PIN for each one. Furthermore, some identity providers might require the user to enter a password or use a smart card each time a new security token is requested with a particular information card. For cards that don't have either of these protections, the user will need to contact each identity provider whose cards have been compromised, informing them that the cards should no longer be accepted. As with acquiring cards, there's no standard mechanism for doing this. Each identity provider must supply its own procedure for a user to cancel an outstanding information card, and then stop honoring requests made with that card.
But what about information cards created by the self-issued identity provider? In the case of a stolen laptop, the identity provider for these cards has also been stolen, and therefore there's no way to tell it to stop honoring requests. This is much like losing a password, where the only solution is to inform organizations that accept this password about its loss. If information cards are lost along with the self-issued identity provider that created them, their owner will need to cancel his or her account manually at each relying party that accepts security tokens created using these now-compromised cards. CardSpace provides a card history feature that records all sites at which a card has been used, so the owner of this stolen laptop can use a backup copy of his or her cards to determine which sites need to be contacted.
Interoperating with Windows CardSpace
Windows CardSpace is part of the .NET Framework 3.0, and applications built on it are necessarily Windows applications. CardSpace-compatible Identity selectors are being implemented on other platforms and devices, however, and identity providers and relying parties need not be Windows applications. This section provides an overview of what those identity providers and relying parties must do in order to work with Windows applications that use CardSpace.
Creating an Identity Provider
Identity providers can be built using any development platform, on any operating system. However it's created, every identity provider must do four things in order to work with CardSpace:
It must be able to create information cards that are compatible with the Microsoft-defined card format, and it must provide a way to get these cards to users.
It must implement a security token service (STS), as defined by the WS-Trust specification. Built on SOAP, this specification defines a standard way to request a particular type of security token that contains specific claims from an STS. Every identity provider must implement at least one STS, but that STS can issue security tokens in any format—no particular token type is mandated. Although not required, it's highly recommended that the identity provider also support specific extensions to WS-Trust that are defined by Microsoft for the identity metasystem.
It must define its policy using WS-SecurityPolicy, and then allow this policy to be accessed using WS-MetadataExchange. As described earlier, every information card contains an endpoint from which an identity provider's policy can be retrieved. This step was omitted in Figures 2 and 4, but before a client application requests a security token from an identity provider, CardSpace first asks the identity provider for the provider's own policy.
It must indicate in its policy how requests for security tokens should be authenticated. In the first release of CardSpace, four options are supported for authenticating users to an identity provider:
Username/password (which might require the user to enter a password for this identity provider each time a card is used)
Kerberos tickets
X.509 v3 certificates (either software-based or from smart cards)
SAML security tokens created by a self-issued identity provider.
An identity provider can choose to support any or all of these options.
As part of its policy, an identity provider can also indicate that the identity of the relying party must be provided when a user requests a security token for that relying party. By default, the relying party's identity isn't revealed by CardSpace to an identity provider when a token is requested. This protects the user's privacy, since it prevents the identity provider from knowing what service the user intends to access with this token. But some identity providers might require knowledge of the relying party's identity before issuing a requested token. A Kerberos server, for example, needs to know the identity of the service the client will access, in order to create a ticket for that service. More generally, an organization that establishes an identity provider for use by its own websites might allow only that identity provider to issue security tokens for use with those sites—no freeloaders would be allowed to use this identity provider for their own purposes.
CardSpace also defines a few SOAP faults that can be sent if errors occur. For example, accessing an identity provider might generate faults indicating that the information card referenced in a request for a security token is invalid or has expired, or that the identity provider was unable to create a security token containing the requested claims.
Creating a Relying Party
Like identity providers, relying parties can be built using any development platform, on any operating system. Also like identity providers, relying parties must do a few things in order to work with CardSpace. The requirements for a relying party are:
It must be able to accept security tokens. The most general approach is to implement WS-Security, but a website can also accept tokens sent using HTTP.
It must define its policy. Once again, the broadest option is to do this using WS-SecurityPolicy, and then allow the policy to be accessed using WS-MetadataExchange. A website can also describe its policy in HTML and transmit it using HTTP.
It must make its certificate available. For a relying party that implements the WS-* specifications, this is done using a Microsoft-defined extension to the WS-Addressing endpoint reference. By adding an Identity element to the WS-Addressing EndpointReference, this extension provides a standard way to expose the relying party's certificate to clients.
Relying parties are free to accept any kind of security token. While it's not required, many relying parties will accept the security tokens produced by CardSpace's self-issued identity provider. (Microsoft defines a specific value that a relying party can place in its policy in order to indicate support for these tokens.) Whatever security tokens a relying party accepts, it is free to map this information into a local identity, converting, say, a SAML token into a Windows security identifier (SID) or a UNIX user identifier (uid).
As with identity providers, CardSpace defines a few SOAP faults that can be sent if errors occur during Web services interactions with a relying party. For example, accessing a relying party might generate a fault indicating that one of the claims in the security token is invalid, or that a required claim is missing.
No comments:
Post a Comment