Friday, July 18, 2014

ADFS : ADFS and SAML AuthnContext

This article gives an good overview of the subject:

Authentication Handler Overview

You'll see that normally ADFS will set the AuthnContext to something like "urn:oasis:names:tc:SAML:1.0:am:password" for FBA.

So what happens if you have ADFS as a SP and the IDP demands something else?

If you have a ASP.NET application as the RP, you're in luck. All you have to do is set the wauth parameter as per this article:

Windows Identity Foundation (WIF): How to Utilize the WS-Federation WAUTH Parameter to Specify an Authentication Type

I normally do this in the web.config.

It seems counter-intuitive. wauth is a WS-Fed protocol element not a SAML one but ADFS obviously has the intelligence to pass this through to the SAML IDP in the AuthnContext.

What happens if your RP is SharePoint. Sadly, in this case you are fresh out of options. There are many references to this on the web but nobody appears to have a solution.

You pretty much have to add a proxy to add this element or speak nicely to your IDP provider!

Essentially you have to deconstruct the AuthnRequest, add the AuthnContext stuff and then put it all back together. That's basically just vanilla XML manipulation. However, if the agreement is that the AuthnRequest has to be signed, it's a whole new ballgame. You now have to get your hands on the private key of the SP signing certificate and read the SAML specifications to see which part of the AuthnRequest needs to be the signing input.

If you have certificate rollover set in ADFS, you again are screwed, The signing certificate is not in the certificate store. It's some weird combination of a certificate container in AD, a blob in one of the attributes and a link to the ADFS configuration database.

In this case, turn rollover off, generate your own certificates, place them in the certificate store in the usual manner and you are good to go. Remember to give the application account access to the private key. If that's all Greek, refer:

AD FS 2.0: How to Replace the SSL, Service Communications, Token-Signing, and Token-Decrypting Certificates

under the "Manage private keys" section.


No comments: