InfoCards in Action

We've covered how to create InfoCards and what's in them (metadata!) but how are they actually used in practice? Figure 14.3 shows the interaction between the user, the identity provider, and the relying party.

Figure 14.3. Basic flow between parties.

Now let's dig into the next layer of detail. Figure 14.4 shows the message flow sequence from the Guide to Integrating with InfoCard.

Figure 14.4. Message flow.

This basic message flow is the same for all InfoCard interactions, with variations based on the number of security token services. For example, the relying party can have an STS controlling access to a resource. This is typically the case with websites where access control is commonly regulated using cookies. Also, as with our language example earlier, there can be any number of identity provider STSes where one security token is exchanged for another until the security token required by the relying party is obtained and presented (this is easily configured in WCF config files).

Let's use a real-world example to make this STS chaining a little clearer. Suppose I want to buy an HP computer from an online retailer and I know that my employer, Microsoft, has an employee purchase arrangement with HP. The retailer also has a relationship with HP; he orders stock from them and accepts HP partner discounts. The retailer needs to see a security token from HP in order for me to get my discount. In turn, to get that, I need to provide HP with proof that I work for Microsoft. So this is what happens:

1. I select my Microsoft provider InfoCard and authenticate to the Microsoft STS using my domain credentials or my smartcard. I receive a security token that has a claim that I am a Microsoft employee.

2. This token is presented to the HP STS. Because the HP STS has a trust relationship with the Microsoft STS, it can see that the token is valid (it's signed using a private key known only to Microsoft), and it checks a proof-of-possession key that helps prove that I am the rightful user of the token.

3. The HP STS issues another security token (signed using an HP cert and with a proof-of-possession key from HP).

4. This security token is presented to the retailer service. The retailer checks the token for validity, sees that it comes from HP and that I am the rightful owner, and gives me my $1 discount.

It is worth clarifying how one authenticates to an STS (you have to prove who you are in order to be issued a security token!). InfoCard supports four ways to authenticate users to the initial identity provider STS: Kerberos, X.509 (software and hardware based), a personal InfoCard, and a username and password. When you select a provider card, you can be prompted for the associated credentials such as a password, a personal InfoCard, a smartcard and pinor the InfoCard system may use a client certificate or your Kerberos credentials, in which case the authentication is seamless.

The identity provider specifies which authentication method to use in the security policy that InfoCard retrieves using WS-MEX. It also obtains security binding information, endpoint information, and the like.

For fine details on interactions between the identity provider, the user, and the relying party, the best place to look is in the Guide to Integrating with InfoCard (aimed at vendors interoperating with InfoCard) and the Technical Reference for InfoCard v1.0 in Windows.

The Kerberos authentication method dovetails nicely with Microsoft's Active Directory Security Token Service when it becomes available. System administrators will use an admin console to set up trust relationships with organizations and define which Active Directory attributes are exposed as claims. Then a user just selects his company's provider InfoCard to gain access to a trusted partner's application or website. All the necessary authentication and access control is done seamlessly and painlessly in the background.