SYSK 184: What Is CardSpace? The Reader’s Digest Version…
In April 2006, David Chappel wrote an excellent article “Introducing Windows Cardspace” available at http://msdn.microsoft.com/winfx/reference/infocard/default.aspx?pull=/library/en-us/dnlong/html/introinfocard.asp. The full article is 25 printed pages long, so this post is an attempt to create a shorter (2-page) version, but retaining the key points.
· We use different ways to identify ourselves based on context – e.g. passport at an international airport, driver license when stopped by police, debit card plus pin at a grocery store, etc. Same applies to digital identities – network login at work, personal e-mail login, login for private sensitive (e.g. financial) sites, etc.
· To minimize the complexity of dealing with so many digital identities, we need a metasystem (system composed of common properties of other systems) focused on identity.
· When transmitted on the network digital identity is represented by some kind of security token. X.509 certificates and Kerberos tickets are examples of security tokens, but they do not allow the conveyance of an arbitrary set of claims. Security Assertion Markup Language (SAML), a standard created by the industry group OASIS, can be used to define security tokens that contain any required set of claims.
· Digital identity can be used not just for authentication, but also for authorization (fact that you are over 21 years old, fact that your credit card doesn’t expire for another year, fact that you belong to company XYZ in a role of ABC, resulting in certain purchasing authority, etc).
· Windows CardSpace (formerly "InfoCard") is a Microsoft .NET Framework version 3.0 (formerly WinFX) component that provides the consistent user experience required by the identity metasystem, and is based on open, published protocols such as WS-Security, WS-Trust, WS-MetadataExchange, and WS-SecurityPolicy. It is specifically hardened against tampering and spoofing to protect the end user's digital identities and maintain end-user control. 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. The next release of Microsoft's Web browser, Internet Explorer 7, will let users rely on CardSpace for their digital identities. However, this solution can't succeed unless other organizations also implement it.
· CardSpace implements an intuitive user interface for working with (storing, changing, selecting) digital identities. Each digital identity is displayed as an information card (InfoCard) represented as a picture. 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.
· The following describes the claim-based authentication process:
- Application gets the security token requirements, a.k.a. policy (e.g. what security token formats the relying party will accept, and exactly what claims those tokens must contain), of the relying party (e.g. an Internet website) that the user wishes to access
- The application passes this information to CardSpace, asking it to request a token from an appropriate identity provider (e.g. ActiveDirectory, a self-issued identity provider for user selected name/password types of identities, etc.). At this point, CardSpace displays the card selection screen to the user showing every information card he or she owns on this system, 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, to the identity provider associated with that card. 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.
- 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.
· 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.
To minimize phishing attacks, websites requesting user identity have to first prove its identity to users. CardSpace will show the user the requestor’s 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).
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.
· What’s in the card?
1. 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.
2. 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.
3. A URL for one or more endpoints at this identity provider that can be accessed to request a security token.
4. 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.
5. The date and time the information card was created.
6. 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.
Note: sensitive data about this identity is not in the card. 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. 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.
· CardSpace provides a card export feature to support roaming users. Exported information cards are encrypted using a key derived from a user-selected pass-phrase.
For more information, visit http://msdn.microsoft.com/winfx/reference/infocard/