The article attempts to give you a quick start on the essential concepts of Windows CardSpace, also after completing this article you will be able to create your own "CardSpace enabled web-page". If this doesn't make sense, please read on. Let's get hold on some of the buzz-words first in order to get a better understanding of the technology .
These are the identities that we use in our digital world (the world of internet) just like we have physical identities (credit cards, licenses etc) in real world. These digital identities come in all shapes and sizes; perhaps you have an e-mail account with Yahoo, or have accounts with various commercial organizations, such as Amazon or eBay, along with identities for sites such as MySpace.com.
Digital Identities are represented by security token, when transmitted on the network. A security token is just a set of bytes that expresses information about a digital identity. 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.
An identity provider is just what the name suggests: something that provides a digital identity for a user, for example, the identity provider is typically a system such as a Government agency that issues you a social security number. The identity provider could be your bank, or college, the identity provider is effectively you, since you define your own username and password. It could be any website such as www.msn.com. 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.
A relying party is an application that in some way relies on a digital identity. A relying party will frequently use an identity (ie.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.
It's a mechanism that prompts the user to choose one of possibly many "information cards" that represent data owned/managed by any number of different Identity Providers, and that match the types of claims required by the Relying Party. Note that the card is just a pointer to the data; it does not contain any data.
Just like we have multiple physical identities suitable for different occasions, no single digital identity can suffice in the digital world too. Also these different identities will be provided from different sources as 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. If it sounds confusing, the next section will make it clearer.
Windows CardSpace is Microsoft's specific implementation of an Identity Metasystem that enables users to choose from a portfolio of their digital identities and use them in contexts where they are accepted, independent of the underlying identity systems where the identities originate and are used.
CardSpace is a software client that runs on Microsoft Windows, and which can participate as an Identity Selector within the framework of the Identity Metasystem, a web services framework that utilizes WS-* protocols to communicate claims between three parties: the Identity Provider (IP), the Relying Party (RP), and the Identity Selector.
Points To Remember
- CardSpace is just one implementation of one part of a 3-part system, many people say "CardSpace" and mean not just the client, but the whole process including identity provider, relying party and identity selector. This is not perfect usage but it gets the general point across.
- The applet that starts CardSpace from the Control Panel used to be called "digital identities" but now it is called "Windows CardSpace".
- CardSpace and Windows Card Services (WCS) is the same thing, and they both used to be known as "InfoCard".
- The CardSpace client is installed as part of the ".NET Framework 3.0″ subsystem (formerly WinFx).
- The CardSpace client can be triggered in two ways:
- From IE7 (Extension for Firefox is also released)
- From a service built using Windows Communication Foundation (formerly Indigo).
- Information cards can be of two types:
- Self-issued (now called Personal): These are the cards that are created by the user, data associated with these cards comes from a local Identity Provider, built into the CardSpace client and editable by users. In the self issued cards there are fixed set of claims (listed at the end of this article) which the user can edit.
- Managed: Data associated with these cards must come from some third-party "authority". The InfoCard only contain the metadata, no real data is stored, when user selects managed card, CardSpace gets connected to the STS (security token service) running on Identity provider by referring the metadata. It is the service that is actually responsible for providing the security token containing the real claims. Users may not edit claims made by these cards using CardSpace, they must go to the third party and use whatever mechanisms the third party provides.
Creating a Web Site (Relying Party) That Accepts Infocard(Information Card)
Let's get on with the step by step process to see how we can create a relying party that accepts the information card (instead of standard username and password) from the user and can decrypt the security token to get the details of the user.
First you have to install the SSL and CA certificates; SSL certificate is the (Secure Sockets Layer) certificate which is a component in securing the channel between the host (your site) and the client. CA certificates are basically the high assurance certificates provided by the certifying authority, grab the sample code provided with this article. Unzip the sample and browse to the sub-directory 'certificates' which contains the required certificates. Follow the document "Installation-Instructions.doc" provided for successfully installing the certificates on your system.
After successfully installing the certificates, we'll set up a directory for our application and create a login.htm page. Using VS 2005 create a new website. Use the IIS manager to create a virtual directory pointing to this directory and give it an alias. We don't use the VS2005 development server since we need an HTTPS (SSL) connection. This login.htm is the entry point into our application. This page will let us select an identity card that we will eventually submit to the site. To allow us to select a card we need to instruct IE 7 to invoke the CardSpace selector.
There are two ways in which we can declare the CardSpace selector within the page; the use of the OBJECT tag or the use of some XHTML. For this sample I've chosen the OBJECT tag. Here are the contents of Login.htm:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
<form id="form1" method="post" action="carddetails.aspx">
<button type="submit">Click here to sign in with your information card</button>
<object type= "application/x-informationcard" name="xmlToken">
<param name="tokenType" value="urn:oasis:names:tc:SAML:1.0:assertion"/>
<param name="issuer" value="http://schemas.xmlsoap.org/ws/2005/05/identity/issuer/self" />
<param name="requiredClaims" value=
Within the object tag requiredClaims parameter is one of the important parameter. This parameter outlines what information the card must send in order to be accepted. You can see that it requires four set of claims first name, the surname, email address and a private personal identifier. The last one here is important as it provides a unique string for this particular card. This is the only claim generated by the built in STS of the CardSpace that the user cannot edit. There is a complete list of claims at the end of this article. So the page is a very simple one .Navigate to this page using IE 7. You'll remember that we've installed a SSL certificate of www.fabrikam.com and CA certificate adatom.com here so the address bar should be green. Clicking this button opens the Card Selector Interface. So, once a user has selected and sent a card to our application what do we do with it? The information that's transmitted to use is over a secure SSL connection and in addition to that, the ticket information is also encrypted. It's XML but we have a little work to do before we can actually read and consume it.
If you go back to the sample application you created you'll recall that the encrypted token is submitted as a standard HTTP variable called xmlToken. This was the name given to the information card Object you created. In order to view this token you need to create a page called carddetails.aspx. This was the target of the form. In our application it will be the responsibility of carddetails.aspx to extract and decrypt the token. It will then simply display the information contained within the card.
<%@Page Language="c#" Debug="true" ValidateRequest="false" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
protected void Page_Load(object sender, EventArgs e)
Label1.Text = Request.Params["xmlToken"] ;
<head id="Head1" runat="server">
<title>Carddetails test page</title>
<form id="form1" runat="server">
The value of the token is:
<asp:Label ID="Label1" runat="server" Text="Label"></asp:Label>
This is a very simple form with one goal, to display the contents of the card that is submitted. Open login.htm, select a card. This will then redirect you to carddetails.aspx and you'll be able to see the encrypted card details. It should look something like this snippet.
Fortunately Microsoft has, as part of the sample kit you downloaded, included a type called Token which takes care of all the decryption and processing of the XML Card. I'm not going to cover this class in detail as it mainly contains Certificate based decryption, which is outside the scope of this article. If you are interested in it however, do open the class and take a look. This will allow you to roll your own class if you see fit. To begin, the xmlToken string must be decrypted.
From the sample you downloaded you should be able to find, in the website/App_Code directory, a file called TokenProcessor.cs. This file contains the Token class I just mentioned. Add this file into your own App_Code directory in Visual Studio. Once you've done this you'll need to modify Carddetails.aspx to call this class so that we can access the details of our Identity Card.
Remove the <script> block from Codedetails.aspx and add four labels with id givenname, surname, email and ppid on Codedetails.aspx. Open the code-behind page and add the following code to the Page_Load method:
Token token = new Token(Request.Params["xmlToken"]);
givenname.Text = token.Claims(ClaimTypes.GivenName);
Showing the Card information
You have to import two namespaces in order to make this code compile correctly, the
System.IdentityModel.Claims namespace and also the
Microsoft.IdentityModel.TokenProcessor namespace . This code will decrypt the token, access the claims within the token and display them to the page. If you navigate back to Login.htm, select a card to submit and send it, you should see a page with this information on it:
These are the value of four claims contained within the card that I submitted. The privatepersonalidentifier uniquely identifies our card.
So that's it. You've just completed a simple end to end application that uses CardSpace.
List Of Claims
I would now like to return to the requiredClaims we've specified. In this example we're only sending four pieces of information but as you have seen, you can include much more. Each of these claims has a particular namespace. Here they are:
- Given Name = http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname
- Email Address = http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
- Surname = http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname
- Street Address = http://schemas.xmlsoap.org/ws/2005/05/identity/claims/streetaddress
- Locality = http://schemas.xmlsoap.org/ws/2005/05/identity/claims/locality
- State/Province = http://schemas.xmlsoap.org/ws/2005/05/identity/claims/stateorprovince
- Postal Code = http://schemas.xmlsoap.org/ws/2005/05/identity/claims/postalcode
- Country = http://schemas.xmlsoap.org/ws/2005/05/identity/claims/country
- Home Phone = http://schemas.xmlsoap.org/ws/2005/05/identity/claims/homephone
- Other Phone = http://schemas.xmlsoap.org/ws/2005/05/identity/claims/otherphone
- Mobile Phone = http://schemas.xmlsoap.org/ws/2005/05/identity/claims/mobilephone
- Date of Birth = http://schemas.xmlsoap.org/ws/2005/05/identity/claims/dateofbirth
- Gender = http://schemas.xmlsoap.org/ws/2005/05/identity/claims/gender
- PPID = http://schemas.xmlsoap.org/ws/2005/05/identity/claims/privatepersonalidentifier
- Web site = http://schemas.xmlsoap.org/ws/2005/05/identity/claims/website
[This list was taken from http://msdn2.microsoft.com/en-us/library/aa395199.aspx]