Hi,
I'm doing an SP-initiated sign-on from a SAML web application to an AD FS 2.0 IdP and specifying an authentication context class URI of urn:oasis:names:tc:SAML:2.0:ac:classes:Password
Logging on to AD FS via the proxy works fine.
Authentication Handler Overview
http://msdn.microsoft.com/en-us/library/ee895365.aspx
I've used the above document as a reference. On the farm side, the Forms handler is listed in my local authentication types within the web.config. Because no comparison attribute is specified in the request, according to SAML specs, this defaults to Exact .. Equally, if ForceAuthn=True is set, existing session cookies are ignored, and provided an authentication context class reference is specified, AD FS will serve up the appropriate authentication handler. Given that the URI specified is password, I would expect to see the forms sign-in page, however, it's ignoring the authentication context class and defaulting to the integrated handler (urn:federation:authentication:windows)
Am I missing something here as the documentation suggests that this is possible? I've done SAML traces and the authentication context class reference is being passed correctly from the SP. As expected, if a user does integrated auth then they're denied at the SP because the class reference doesn't match. I understand that in IdP initiated sign-on scenarios some customization is required, but in SP-initiated scenarios I would expect this to work. I could always pass the appropriate desired context back via a custom claims rule, but I want to force forms logon, i.e. break SSO for this particular SP..
Regards,
Mylo