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.
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:
- Claims arrive at your STS party (Idp) which is ADFS
- Then are mapped
- Then sent onto the relying party in ADFS specified in your RST AppliesTo
- Then they are mapped
- Then sent back in the security token back from ADFS.
In R-STS, actually what happens is:
- Claims arrive at the original STS party (Idp) which in my case is the StarterSTS claim issuer
- Then are mapped
- Then sent onto the relying party in ADFS specified in your RST AppliesTo (but for the R-STS security token request)
- Then they are mapped
- 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 for sharing this info!
Can you please show some config of the RP?
I don’t get it how to authenticate (in my case ADFS) and get claims from StarterSTS.
I am actually authenticating to StarterSTS using a custom forms authentication membership provider. I do not authenticate to AD.
I found out that StarterSTS 1.2 doens’t support issedtoken.
And version 1.5 is discontinued, so i’m trying to write a very simple R-STS as claimprovider now.
You can have StarterSTS v1.2 create a token and then call an issued token endpoint over ADFS. I am using StarterSTS v1.2 for all of my posts up to this point.
Yes is works!!
Everyone please buy the book “Programming Windows Identity Foundation”.
It let me fix my few days problem in a few hours!
Create a Sample STS from the WIF SDK Templates.
Set this STS as Relying Party in ADFS.
Add a STS Reference in the Sample STS to ADFS and test it.
Create ClaimAware site (again from the templates)
Add a manual reference since the FederationMetadata isn’t reachable from the website to your Sample STS.
Follow some simple steps in the Sample STS like set the realm etc.
Now it works!
I want the ADFS as Identity Provider with windows auth.
So for me its the other way around.
With the other way around I think this should work too (but this post does not show how) for authentication but the claim mapping would be all .NET code. StarterSTS would be the relying party specified in ADFS.