What you always wanted to know about Microsoft Cardspace - Part 1
Since the Identity Metasystem and Microsoft Cardspace is quite a complex topic but is a great means to enable the user to have better control how and when identity information and login credentials are used I felt that there needs to be some more clarification about certain aspects of Microsoft Cardspace. Therefore I will start a series of FAQs. And here's the first part. I hope you will find this helpful.
Q: Can a managed card be used without typing a user name and a password?
A: The direct answer to this question is yes, that's definitely possible. However does this also mean that a managed card can be used without authentication? To this question the answer is a definite no. This means that a user always has to provide some sort of authentication credentials to have the identity provider create a security token with the user’s claims in it. But there are several ways for providing those authentication credentials and it is up to the identity provider to decide on which option is required.
- UserNamePassword: the user is prompted for a username and password before when the Request Security Token (RST) is sent.
- KerberosAuth: when this option is used the windows login credentials are transferred as a Kerberos token which makes it not the preferred option for internet scenarios.
- SelfIssuedAuth: in this case a Private Personal Identifier (PPID) generated for a self issued card is used to authenticate the use of the managed card. If the card is not available on the system authentication will fail.
- Smartcard: in this case an X509 certificate is used to authenticate. This can also be a soft certificate.
The option to use will be encoded in the card itself which means the decision has to be made before the card is created and it is not dynamically changeable. For the sample card creation application available from Microsoft the authentication process must be specified in the [CARD] section of the initialization file.
[CARD] ; type is one of UserNamePassword,KerberosAuth,SelfIssuedAuth,SmartCard, TYPE=SelfIssuedAuth
Q: How does an identity provider provision a card to the user?
A: The card is a physical file which carries a file extension of .crd. This physical file has to be transferred to the user. There are no restrictions on what channels are used for the transfer. This can range from e-mail or download or even a floppy disk or CD sent via normal mail. After the user received the card file it needs to be installed into the card selector on the target PC. In this context it is worth mentioning that a card file of a managed card does not include any personal information of the user but only the metadata on how to retrieve the actual, card specific set of claim information in form of a security token from the respective identity provider.
Q: Can a service provider decide on the identity providers he accepts managed cards from?
A: Yes the service provider can specify one or a set of identity providers which he accepts cards from via his policy. This means the service provider must provide valid, WS-Addressing compliant issuer endpoints in his policy within a sp:IssuedToken/sp:Issuer section. In this case the card selector should only highlight cards which
- Are issued by one of the specified issuers
- Can provide the set of claims requested by the service provider
If no such card is available in the card store the card selector will display a corresponding message to the user. In order to have matching endpoint information for this selection of issuers the identity provider must specify a corresponding endpoint/logical name in the ic:Issuer field of the initialization file for the card creator.
Q: Can an identity provider decide on with which services or service providers his card can be used?
A: Yes this is possible. There are two modes in which the RST can occur. Those are:
1. Non-auditing which is the default will not include information about the service provider in the request for a security token.
2. Auditing. In auditing mode the request will include endpoint information of the service provided by the relying party.
As non-auditing is the default no action has to be taken to enable this mode. However if the identity provider wants to operate in auditing mode. The <ic:RequiresAppliesTo /> element needs to be included in the identity provider's policy. However it is worth noting that as Cardspace and the principles of the identity metasystem are based on full control of the user the identity provider should inform the user about gathering information about the usage of the card in his privacy statement.
Q: Does the identity provider get information about when his card is used?
A: This is related to the question right before and can be answered accordingly. The identity provider can always collect information about when the card is used as the card itself doesn't contain any claim information and whenever the card is used a RST is sent to the identity provider who then generates a security token. However if the identity provider uses the default non-auditing mode then the provider does know when and how often a card was used but not for which services or service providers.
... to be continued soon.
More information can also be found here:
Comments
- Anonymous
September 25, 2007
PingBack from http://www.artofbam.com/wordpress/?p=2990 - Anonymous
February 07, 2008
The publication of Vittorio's book "Understanding Windows Cardspace" about which I wrote a post only - Anonymous
February 07, 2008
The publication of Vittorio's book "Understanding Windows Cardspace" about which I wrote