The other day, Travis Nielsen wrote an article about how to use ADFS in conjunction with an OpenID provider (OP) to authenticate users accessing a SharePoint 2010 site. His article is really good and definitely worth reading. As he says in it, he based his work on Matias Woloski's which is also a must read. Travis proposes a solution that, if implemented exactly, will include five token services. Something like this:
I like this stuff a lot, but that's too many STSs if you ask me. Instead, I would suggest doing away with the the protocol transition STS (as Matias called it) and instead customize ADFS's login app to thunk between WS-Federation and OpenID. Building a proof of concept (PoC) to demonstrate this using Matias' code was short work. Here's how I did it:
1. I changed IIS, so ADFS would use my own login app rather than the one that it comes with. I did so by modifying the IIS "ls" application to point to some other directory. You can also do this by modifying the Windows Internal Database (WID), but I wouldn't recommend that.
2. Then I dumped Matias' code into this directory and modified it a tiny bit. (My code can be found in this ZIP file.)
3. I didn't have SharePoint 2010 set up, so I used one of the passive RPs that come with the WIF SDK as a substitute. I changed the issuer URI to that of ADFS's passive endpoint (i.e., https://.../adfs/ls). Then, I pulled it up in my browser. I was redirected to ADFS's new login app.
4. Once there, I entered my OP's endpoint.
5. This redirected me to my OP, and I logged in.
6. I was redirected back to the ADFS login app (passive STS) which thunked the OpenID response to a WS-Federation response. I was then redirected to the RP (which would be the SharePoint RP-STS in the actual case). The RP displayed the claims which included the name and ID issued by the OP.
I know what you're thinking. Surely there's stuff in ADFS's login app that can't just be thrown out like this. Definitely. This isn't a finished product in any sense. It's just a demonstration of how you can protect a SharePoint 2010 site using 4 STSs instead of 5.
I like this stuff a lot, but that's too many STSs if you ask me. Instead, I would suggest doing away with the the protocol transition STS (as Matias called it) and instead customize ADFS's login app to thunk between WS-Federation and OpenID. Building a proof of concept (PoC) to demonstrate this using Matias' code was short work. Here's how I did it:
1. I changed IIS, so ADFS would use my own login app rather than the one that it comes with. I did so by modifying the IIS "ls" application to point to some other directory. You can also do this by modifying the Windows Internal Database (WID), but I wouldn't recommend that.
2. Then I dumped Matias' code into this directory and modified it a tiny bit. (My code can be found in this ZIP file.)
3. I didn't have SharePoint 2010 set up, so I used one of the passive RPs that come with the WIF SDK as a substitute. I changed the issuer URI to that of ADFS's passive endpoint (i.e., https://.../adfs/ls). Then, I pulled it up in my browser. I was redirected to ADFS's new login app.
4. Once there, I entered my OP's endpoint.
5. This redirected me to my OP, and I logged in.
6. I was redirected back to the ADFS login app (passive STS) which thunked the OpenID response to a WS-Federation response. I was then redirected to the RP (which would be the SharePoint RP-STS in the actual case). The RP displayed the claims which included the name and ID issued by the OP.
I know what you're thinking. Surely there's stuff in ADFS's login app that can't just be thrown out like this. Definitely. This isn't a finished product in any sense. It's just a demonstration of how you can protect a SharePoint 2010 site using 4 STSs instead of 5.
Hi Travis,
First of all, this is a very interesting idea. However, I was unable to fully grasp the solution:
1) How does the "ls-mine" app connects with the ADFS 2 runtime? Namely, how are the claims extracted from the OpenID response given to ADFS 2 runtime.
2) I've looked into the source (ls-mine.zip) and was unable to see how this connection is done. I observed that you insert the openid's claims into the current session and then retrieve this information on a *custom* STS. However, how are these claims processed by ADFS 2?
Thanks
Pedro
The "ls" IIS application, which is ADFS's default endpoint for passive clients, was updated to point to the "ls-mine" directory which contained the custom code from the ZIP file. ADFS is already configured to use this endpoint, so its metadata will point RPs to it. In actuality, this reference in ADFS's metadata is the only real connection to the code I uploaded, and this PoC is just a custom STS that doesn't use ADFS to issue tokens. If I was doing this for real, I would not do the translation myself; instead, I would use WIF to create an OnBehalfOf request and send that to ADFS's WS-Trust endpoint with the the OpenID token. I don't think ADFS would be able to validate the signature though because it doesn’t have a handler for that type of token (and the list of handlers can't be extended). If this didn't work, I would just send in a normal RSR that is signed by the "ls" app not the OP. Regardless of how it's done, it would be best if ADFS did the actual transformation of the token. This way its issuance language with its authorization policies and whatnot could be leveraged. If I have the time, I'll update the PoC to do this, and post a comment here with details.
My point with all this wasn't that this is how you should integrate ADFS, SharePoint, and OpenID. Rather, it was that this integration can and -- I dare say -- should only include four STSs not five. Through this PoC, I was trying to demonstrate that this could be done by customizing ADFS's login application (in some way), thus, avoiding the need for an extra custom STS.