<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
<div class="">At this point in time we have forced users coming through for these applications by identifying "wauth=<a href="http://schemas.microsoft.com/ws/" class="">http://schemas.microsoft.com/ws/</a>“ in the query to authenticate off of ADFS by setting
the MSISIPSelectionPersistent cookie at the load balancer.</div>
<div class=""><br class="">
</div>
<div class="">Not ideal - but a valid workaround until we can sort out the ADFS issue</div>
<div class=""><br class="">
</div>
<div class="">Cheers</div>
<div class="">Aaron</div>
<br class="">
<div>
<blockquote type="cite" class="">
<div class="">On 13 Nov 2014, at 7:20 am, Mike Wiseman <<a href="mailto:mike.wiseman@utoronto.ca" class="">mike.wiseman@utoronto.ca</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">Hi,<br class="">
<br class="">
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:<br class="">
<br class="">
<a href="http://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/password" class="">http://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/password</a><br class="">
<br class="">
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. <br class="">
<br class="">
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:<br class="">
<br class="">
urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified<br class="">
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport<br class="">
<br class="">
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.<br class="">
<br class="">
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?<br class="">
<br class="">
Mike<br class="">
<br class="">
Mike Wiseman<br class="">
Manager, Information Security<br class="">
Information Technology Services<br class="">
University of Toronto<br class="">
<br class="">
This email and any attachments contain privileged and / or confidential information for internal University of Toronto communication only unless otherwise indicated.<br class="">
<br class="">
-- <br class="">
To unsubscribe from this list send an email to users-unsubscribe@shibboleth.net<br class="">
</div>
</blockquote>
</div>
<br class="">
<span style="font-size: 9.0pt; font-family: 'Calibri'; "><em><strong><br>
Important Notice:</strong> The contents of this email are intended solely for the named addressee and are confidential; any unauthorised use, reproduction or storage of the contents is expressly prohibited. If you have received this email in error, please delete
it and any attachments immediately and advise the sender by return email or telephone.<br>
<br>
Deakin University does not warrant that this email and any attachments are error or virus free.</em></span>
</body>
</html>