A few month ago I learned something about claims based authentication that I thought was not possible.
Ever since starting working on federation solutions, and learning about it via training courses, reading white papers, specifications and presentations the following two topologies were always shown or discussed. The first one is where company has its own STS and their applications configured with this STS. The second solution extends on the first one by federation between two STSs, where one STS is acting as RP and the second is acting as IdP. I have never seen any specs or designs that would show more than two STSs in a chain, ie something like this RP-RP-IdP. So for some time I was assuming that protocols that make it all happen (WS-Fed, SAML etc) are designed to work in specific model RP-IdP and would not go beyond this one-one relationship. While this works for majority of the real world situations, in some cases it does not satisfy the complex requirements where chaining of the multiple STSs is required. Well, I thought that it was not possible till a few month ago. I had to design complex federation architecture and this perceived limitation was giving me a lot of headache. So, obviously I did some research and talked to a few people who also specializes in federation solutions and to my great surprise I learned that there is no limitation with protocols and that it is just fine to setup multiple STSs in a chain of trusts. I wish that I learned it prior from someone else’s design or spec paper, clearly stating that it is fine to do this and it will work. Needless to say, we were able to configure our architecture and satisfy customer requirements without additional overhead and keep it very streamlined.
A few days ago I was rebuilding my lab and decided to configure it to illustrate chaining of multiple STSs and show it here. So if anyone else didn’t decipher it in spec papers or other design, and is thinking that chaining is not possible, that it is in fact possible and works just fine. You can use it in your designs if it is a requirement.
In my lab I configured the following to illustrate this configuration:
- IdP STS (DC, AD FS 2.0), it has the following FS URL: fs1.contoso.com
- RP STS (AD FS 2.0), this is a middle STS, with FS URL: fs2.contoso.com
- RP STS (AD FS 2.0), this is the STS with target relying party application. FS URL: fs1.external.com
- Relying Party (Sample WIF SDK app). This is a workgroup server configured with fs1.external.com as its STS. Application URL https://myclaims.external.com/myclaims
- Workstation that will access the application. I have HTTPWatch installed on this PC to show all traffic passive request traffic between the browser and the target systems.
Figure 1 shows my lab configuration:
Figure 1: Chaining multiple STS
Figure 2 shows the HTTPWatch traffic captured on the client PC. As you can see in steps 1 to 10, the browser steps through all parties in the authentication process and authenticates me into the application. It is fairly self explanatory, but if you have questions then let me know if you need any explanation on what happens here.
Figure 2: HTTPWatch capture of the Passive Request traffic with multiple chained STS (click on it to see it large)
Finally, you might ask why would anyone need to chain STS in such way. To answer it I’ll have to write another blog post. So stay tuned, I might do that in the next month or so.
Thanks, Dmitrii
