ADFSv3 IdP3.3 differences from v2

Cantor, Scott cantor.2 at osu.edu
Fri Mar 24 17:25:39 EDT 2017


On 3/24/17, 5:12 PM, "users on behalf of O'Dowd, Josh" <users-bounces at shibboleth.net on behalf of Josh.O'Dowd at mso.umt.edu> wrote:

> Is the solution for supporting the MS Authentication Context >(http://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/password) in
> IdP3.3 as easy as adding that to the list of supported principals in our authn/MFA flow(our default flow), in the
> /conf/authn/general-authn.xml, like:

I don't know anything about the the application issue you're referring to since ADFS doesn't to my knowledge issue requests that insist on any particular AuthnContext class, but in terms of supporting some particular class, yes, you need it to be supported by the MFA flow, and you need it to be supported by whatever specific flow the MFA flow is planning to invoke in response to that choice, and you need to ensure that the AuthenticationResult(s) produced include a custom Principal matching that value (which is generally though not always automatic).

Adding something to the MFA flow alone by definition can't do anything by itself because the MFA flow doesn't do authentication, it only orchestrates other flows that do.

> …  then maybe a RelyingPartyOverride for the ADFS entites where the SAML2.SSO profile sets a defaultAuthenticationMethod to
> the MS Authentication method?

An SP requesting something overrides anything set in that property. That property is for controlling behavior for SPs that can't just ask for what they want.

Of course, it is generally nonsense for any SP to *request* password authentication. That quite literally prevents MFA from happening in a variety of scenarios. But you can't fix that at the IdP. You can prevent an SP from requesting that by disallowing the RequestedAuthnContext feature for that SP, but in doing so, you'd cause those requests to fail.

-- Scott




More information about the users mailing list