Next, we enable the httpmodule FederatedAuthentication, by modifying the web.config as shown in

Well, look at that. There are a lot of interesting controls, that would deserve a post (or a series of post) of their own, but for the task we want to accomplish today the control InformationCard seems to be the best suited. Let's drag it on the page.

Here we go! Finally, a nice control for driving the CardSpace experience. As you can see for the look & feel, this is completely integrated with the Visual Studio experience: the ">" button on the right edge suggests that there's a wizard there:

Nice. The control offers me an easy way of specifying which kind of card I want to ask for. The default is Personal Card, and that's reasonable; but in this case we are interested in accepting managed cards. Let's select it via the drop down and see what happens:

The option Configure Claims changed to Load managed card. Let's try it:

Interesting dialog, containing some of the key info about the token we'll accept. Let's load one of the cards issued by our IP:

As you can see highlighted, Information about the STS endpoint has been extracted from the card; and the Claims button is now enabled, suggesting that we can now select which claims we are interested into. Let's click on it:

Very straightforward dialog. The set of claims correspond to what our STS is capable of emitting, and for every claim we can choose if we mandate it, consider that optional or not request it at all. Let's say that we want to have the name (first claim) and our custom claim accent (4th and last claim), so that our page can give personalized advices about public speaking: we just reflect our choice in the radio buttons and it's all set. It seems long, because I had to explain all the steps and take screenshots, but in fact it is braindead easy.

Now that we defined our policy, let's move our attention to the appearance of our control. We can use the many properties it features, for example here we changed the SignInText (since we the token we are asking will not be used for signing in) and we set DisplayRememberMe to false, since that would not makes sense in a non-signin scenario:

Very cool. The last thing left to address is the behavior of the control itself. As we said, we won't use this token for creating a session: this means we won't take advantage of any automated procedure for validating incoming tokens against a signin policy and we won't need to transparently create a session. The way of communicating this to our httpmodule is via the SignInMode property, that we will set to Single.

Next, we need to provide our logic. Where should we place it? Good news. ADFS "2" Identity Framework exposes a series of events which represent different stages in the token processing pipeline:

Some of those events do not make sense in our scenario (like SignedIn). The right place for our code is SecurityTokenValidated: I don't want to execute before validation, because that would be a waste of precious CPU in case