ADFSv3 IdP3.3 differences from v2

[O'Dowd, Josh]

Thanks.

> 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

Well, I am referring to the doc in the shib wiki that I referenced in my orig post.  It suggests that for ADFS v2 and v3, that a duplicate authn/Password flow needs to be created, and wired for that MS Authentication Method.  A large portion of that article, in the#ADFSv2 section is dedicated to the problem.  One of the bullets under the ADFSv2 section is entitled, " Define a second login handler that is capable of responding to Microsoft's non-standard authentication context:".

The doc indicates a need to address that issue again if using ADFSv3.

Again, I am just trying to figure out if that is in fact an issue, and if so, can IdPv3.3 handle that more gracefully than a duplicate authn/Password flow..

Thanks again,

Josh

-----Original Message-----
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Cantor, Scott
Sent: Friday, March 24, 2017 3:26 PM
To: Shib Users <users at shibboleth.net>
Subject: Re: ADFSv3 IdP3.3 differences from v2

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/authenticationmetho
> d/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


--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net