Developing a minimal STS with ADFS "2" Identity Framework (Part III: Creating a Relying Party)

All right! Welcome to the last installment of this unusual multipart post: this time we are going to see how the ADFS "2" Identity Framework makes creating an RP a trivial task.

Previously, on Vibro.NET:

One of the comments to my breakout session at TechEd suggested that the demo I've shown was too simple to be realistic and that I probably skipped key development tasks: while, in fact, I coded the entire demo on stage. Since I can't show the recoding of the session directly from my blog, the next best thing was to create a walkthrough in which I more or less go through the same steps. In Part I I've shown how to write a simple STS; in Part II we explored how to issue cards associated with that STS; in this Part III we'll create an RP that consumes the tokens issued by our STS.

And now, the conclusion:

Creating an RP is pretty simple to begin with. You get a web page, you add a suitable HTML object tag with the policy that points to your STS of choice, you add server side code that authenticates the incoming token, and you're done. On the other hand, those are tasks that as of today you have to do every single time you create an RP: there's obviously an opportunity for supporting many of those tasks via tooling. Furthermore: the token validation process requires some attention. As of today on our platform we offer some sample code that can be used for the purpose (ever met TokenProcessor.cs), and in general WCF offers advanced capabilities that can be used for the task; however, this is suboptimal. Apart from the little matter of code quality & support, there is the fact that token processing is a fairly specialized task: if we can surface just the aspects that are relevant to the task, we can protect the developer from having to understand all the subtleties that programming at the WCF level entails. We should also integrate with other technologies & practices: for example, we may think that plugging in the membership provider mechanism may be a good idea.

Long story short: we are addressing those RP issues as well (but please remember, all this comes from a sneak peek and subject to change (including as a consequence from you feedback! If you have an opinion, please share it!)). ADFS "2" Identity Framework offers an HttpModule (already seen in Part I) that makes much of the validation work, and a set of visual controls that allow to define the authentication experience via simple point & click, in complete integration with Visual Studio. Sounds nice, eh?

Let's go ahead and see how we can use those features for writing a simple RP. In this case we will write a page which is facading some code that needs access to the claims our STS can provide; we are not going to use the token for signing in & creating a session. It would be pretty easy as well, but it's not what I've shown so I'm sticking to the script.

Let's create an RP via Point & Click

We need to add a new website to our solution; let's call it Demo2.


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

Then, let's turn our attention to Default.aspx. We want to provide the user with a mean of sending us a security token containing the information we need for conducting our business. Let's see what we have in the tooklox, and if there's something that could help:


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 of requests that are destined to fail. Let's type the name of our handler and let's hit enter for generating the handler.


The code is the silliest you can think of: I just extract the claim and do something for reacting to the hardcoded values we set in the STS project.

And we're done! Again: it seemed long because I had to take a screenshot every time something happened, but if you think about it this was ridiculously quick. Few clicks were enough for moving from the default default website project to an RP. Let's give it a try:


No surprises so far. Let's click on the button:


The only card that the website accept is exactly our card. Good sign. Let's go ahead and send it:


..ominous music...


And here we are. The RP examined the claims emitted by the STS about me and run its complex logic for outputting this pearl of wisdom, that I'll hold dear for my next speaking engagement.


That's it: we closed out end to end scenario, and took the chance to showcase what ADFS "2" Identity Framework can do at this point in time (actually, I barely scratched the surface even at thsi point in time. It can do so much more!). It is work in progress, please don't forget it, but hopefully that gave you a glimpse on the fact that we are working on the development aspects of creating claim based solutions. If you have feedback or asks, please do not hesitate to drop us a line. As usual, the more (& the earlier) the better 🙂


PS: I don't know if I'll blog more before leaving for vacation, and I don't know if I will blog while in Italy (somehow I doubt it): just in case, happy holidays! 🙂

Comments (6)
  1. Hi V.

    how are you ? Marry charismas ( I know it’s a bit early )

    Any way, a few things:

    1. The channel 9 video, which has some problems with it, is it still relevant for STS2 ( & ADFS 2) ? or were there changes ( there’s a new OpenID 2 )?

    2. I was looking for the direct link for the sample source, and didn’t find it, did you post it yet ? ( perhaps I missed it ? )

    3. When would the ADFS 2 be available to the general public (CTP) ? ( again, perhaps I missed it ? )

    4. Would there be support for OpenID 2 in ADFS 2 ?

    Any info would be grately appreciated

  2. Hello Adlai,

    Merry Christmas to you too 🙂

    1) the channel9 video is about ws-trust: the posts show a sneak peek of something that will support it, but that does not imply any change in the protocol itself. I am not sure I understand the reference to openid bin this context?

    2) there’s no code, since it would not be of any use (the sample refers to a non public build)

    3) & 4) there are no further info about ADFS "2" at this point

    thanks 😉


  3. Pavel V. Smirnov says:

    Hi Vibro,

    Windows Server 2008 is already out there and so is ADFS "2". I tried it and managed to achieve federated authentication with SAML tokens but without information cards. And there is no any sign of built-in support of infocards or API you mention in these posts on ADFS "2". Could you please tell us some more about this API. How it will be released and when?

  4. Hello Pavel.

    ADFS "2" is not "out", as you put it. If you remember my first post on the topic I wrote:

    ADFS “2” is a codename for a project in which we are developing our next generation claims based identity & federation technologies in support to the industry vision for an Identity Metasystem: it includes a server component and a developer framework.

    I never said in any place that it would have been out in Windows Server 2008 🙂

    As of today I can’t tell anything more about release times & modes: please keep an eye here, you can be sure that as soon as I’ll have the green light I’ll share the news!

    thanks for your interest,


Comments are closed.

Skip to main content