Microsoft Clients Specify Unsupported Authentication Context

[Mike Wiseman]

Hi,

We've noticed in the last week or so that SAML requests from our on-prem ADFS to our Shibboleth idp handling Office 365 are including a RequestedAuthnContext and AuthnContextClassRef of:

http://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/password

These are coming from new Microsoft rich clients that apparently have changed how authentication is being done - I don't have docs from Microsoft on hand so I don't know exactly what's going on yet. Up to now, rich client authentication was handled by ADFS and web authentication was handled by Shibboleth. 

The idp responded with a SAML 'AuthnFailed' response due to the inability to handle the specified authentication method. I did a little testing and tried to add the authentication method to the RemoteUser login handler (idp v-2.3.8). So the login handler was configured with three methods instead of two - the existing two are:

urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport

This resulted in the SAML request being accepted, and the rich client environment presenting the end user with our webSSO login page (!). But, on processing of the credentials, the idp sent another AuthnFailed response saying that the login handler used one of the existing authentication methods instead of the one requested. In doing some googling, I saw a similar question in which the answer was that LoginHandlers are fixed to handle specific authentication methods only and that a new LoginHandler must be built to handle new methods even if the method identifier is meant to invoke an existing authentication method.

We are working on a few possibilities - one is getting the ADFS SP to alter the SAML request. But for now, would I need to write a custom Login Handler for the new authentication method? Any other thoughts?

Mike

Mike Wiseman
Manager, Information Security
Information Technology Services
University of Toronto

This email and any attachments contain privileged and / or confidential information for internal University of Toronto communication only unless otherwise indicated.