Introduction

If you have been following along, you know I have been playing with the R-STS scenario quite a bit lately. I have many, many more posts to do on this topic and I am working on these so stay tuned. Tonight I worked through a couple of hurdles in my R-STS and finally got the claims to map through ADFS 2.0. For my R-STS, I am using Dominick Baier’s StarterSTS (http://startersts.codeplex.com/) with a custom authentication provider (using a SQL user store) and then adding on some custom claims. Then I pass the resulting token into ADFS 2.0 and handle some custom claim mapping and a reissued SAML token with the final set of claims. For a long time I had been struggling to get ADFS to handle the custom claim mapping. Finally I figured out what was happening. In this post I just want to give some more information.

Details

In ADFS you can configure claim issuer trusts and relying party trusts. When you are doing an R-STS scenario, you end up with at least 2 claim issuers and at least 1 relying party. Most of the content out there is on passive federation and single STS scenarios; there is not as much information on active federation or R-STS scenarios. This makes everything more complicated. Understanding the claim procesing flow is the key. I finally started digging into some of the claim pipeline like in this article: http://technet.microsoft.com/en-us/library/ee913585(WS.10).aspx. But again, this is really more about an STS scenario rather than an R-STS scenario.

So reading this article it is easy to see that the processing order for an STS:

1. Claims arrive at your STS party (Idp) which is ADFS
2. Then are mapped
3. Then sent onto the relying party in ADFS specified in your RST AppliesTo
4. Then they are mapped
5. Then sent back in the security token back from ADFS.

In R-STS, actually what happens is:

1. Claims arrive at the original STS party (Idp) which in my case is the StarterSTS claim issuer
2. Then are mapped
3. Then sent onto the relying party in ADFS specified in your RST AppliesTo (but for the R-STS security token request)
4. Then they are mapped
5. Then sent back in the security token back from ADFS

I had been struggling with understanding the execution order. I had been trying to put the claim rules on the built-in “Active Directory” claim issuer because this was leg 2 of my R-STS scenario but ADFS is smart enough to pass these claims right through the built-in claim issuer. You still need to configure a pass through claim rule on both the original STS claim issuer and the relying party but everything flows through as expected.

Some hints that helped me today to accomplish this are:

– Output the claims after every token is returned. This helps you to start thinking about the pipeline.
– Start out with a claim rule in ADFS that does not evaluate incoming claims conditionally. So for example, try a hard coded claim rule like this (from http://technet.microsoft.com/en-us/library/dd807118(WS.10).aspx):

=> issue(type = “http://test/role“, value = “employee”);

The rule above just adds a hard coded claim to the resulting claims. Another helpful tip is that the rule above can issue any claim type even ones not documented in the claim descriptions of ADFS. So you can basically inject claims here without registering them with ADFS. This is both a nice flexibility and a challenge because this can hurt your debugging.

But if you are just trying to figure out where claims get injected into the pipeline, add the rule above to your relying party to just get a claim to show up on the returned token.

– Keep all the built-in Active Directory claim issuer rules in place because these are good examples. Also review the rule syntax for the rules to get a better understanding of what is happening.

Let me know if you have any questions and I will keep posting some lessons learned on my adventures with ADFS!

Thanks,