What happened behind the scene in Card Space
Yes, i am sure quite a lot of people have already seen the great card space UI. But if you are like me who wants to understand the message flow and what is in the card, here are the answers.
First, let me define three interesting parties here:
1. User is the person who would click on the card space UI;
2. IP is the party which create and distribute a card and issues a token;
3. RP is the party which accept the token and extract the claims out of the token for authz;
Let us described based on what User has to prove his/her identity:
1. Username/Password
Card distribution: User A login to a IP site using Username/password, the site provides the user A with a card C which contains the Username, username import this card through the card space UI;
Token issurance: When user A wants to talk to RP, it finds that it needs to select the card C, it will pop up a UI asking for username/password again, then a RST message gets generated with some information, such as claims, copied from card C to the RST message body, it also adds the username token to the security header, encrypt the username token using IP's certificate, and sends the RST to IP; IP then validates the Username and password, hence creates the token it was asking for, sends the RSTR back to the user A;
2. x509 cert or smart card
Card distribution: the site provides the user A with a card C which contains the user A's cert's issuer number or something which can identify the x509, User A import this card through the card space UI;
Token issurance: When user A wants to talk to RP, it finds that it needs to select the card C, it will pop up a UI asking for smart card or it will just go to your cert store trying to retrieve the cert, then a RST message gets generated with some information, such as claims, copied from card C to the RST message body, it also adds the user A's x509 cert to the security header, sends the RST to IP; IP then validates the cert, hence creates the token it was asking for, sends the RSTR back to the user A;
3. kerberos
Card distribution: the site provides the user A with a card C which contains the user A's spn, this is optional. User A import this card through the card space UI;
Token issurance: User A logged in using its Kerberos identity. When user A wants to talk to RP, it finds that it needs to select the card C, A Kerberos token was created between User A and IP, then a RST message gets generated with some information, such as claims, copied from card C to the RST message body, it also adds the user A's kerb token to the security header, sends the RST to IP; IP then validates the kerb token, hence creates the token it was asking for, sends the RSTR back to the user A;
4. self-issued
Card distribution: the card can be created through the card space UI. The card space built-in STS would create the card and the card usually contains a PPID which is unique.
Token issurance: When user A wants to talk to RP, it finds that it needs to select the card C, then a RST message gets generated with some information, such as claims, copied from card C to the RST message body, the unique PPID will be included in this case. The user A then sends the RST to built-in STS, it uses the PPID to look up user's information, then it creates the token it was asking for, sends the RSTR back to the user A;
An interesting fact is that in the self-issued case, User A didn't not provide any credential, and therefore, its claim might be bogus. All it guarantees is that user B cannot get user A's card working on user B's machine. But yes, user B can still put user A's name when it is creating its own card, and the RP would not be able to tell. This is similar to the fact that when you are creating a MSN account, you can put any name and email address there, and there is no way to stop that.
After the token gets issued, the rest is straight forward, the issued token can be used to protect the message flow between User and RP just as usual, and RP can use some of the claims from the issued token for further authorization.