Giving an SP the authnContextClassRef they asked for

[Wessel, Keith]

So, I'm closer to what I need here. But I'm still running into problems on the sending side to ADFS which I thought I had worked around.

If the SP doesn't include a requested authn context in the authn request, I can force MFA or no MFA using defaultAuthenticationMethods. It looks for this particular SP, however, that this trick won't work because of the explicitly request for PPT.

My bean that tells ADFS what's needed looks at the ACRs from the request. From what I can tell, setting defaultAuthenticationMethods for an SP adds to the requested ACR values since my bean is picking that up. But it doesn't seem to replace what was already there. End result: the request is getting sent to aDFS with my password-only configuration.

Can I do something to remove the requested acr from the request? I was hoping to avoid writing another bean with a translation strategy for this rather disgusting edge case. Is that going to be the easiest way to do this?

Thanks,
Keith


-----Original Message-----
From: Wessel, Keith 
Sent: Thursday, January 13, 2022 9:57 AM
To: Shib Users <users at shibboleth.net>
Subject: RE: Giving an SP the authnContextClassRef they asked for

Thanks, Scott. I saw that note in the docs, but it wasn't clear enough to me what the rationale would be.

I'm actually still calling this from within the MFA flow so that I can use logic in the MFA flow to fall back on built-in password and Duo for non-browser interactions. The MFA flow is just calling the proxy flow if it is a browser calling. So, sounds like the property would get ignored based on your first reply.

Thanks much.

Keith


-----Original Message-----
From: users <users-bounces at shibboleth.net> On Behalf Of Cantor, Scott
Sent: Thursday, January 13, 2022 9:51 AM
To: Shib Users <users at shibboleth.net>
Subject: Re: Giving an SP the authnContextClassRef they asked for

On 1/13/22, 10:48 AM, "users on behalf of Cantor, Scott" <users-bounces at shibboleth.net on behalf of cantor.2 at osu.edu> wrote:

>    I'll check the docs, I may have not noted what the default for that flow actually is.

Which would have made for a shorter answer. The text under the property reference table is:

"While the default principal support is a typical password-centric set, in most cases the addDefaultPrincipals property is left false and the values used in responses will be mapped from the value supplied by the proxied IdP. However, to handle requests properly, the supportedPrincipals property may need to be adjusted to account for the possible values that SPs should be allowed to request."

Which is the short equivalent of what I just wrote, with the addition that "may need to be adjusted" specifically means "if the flow is used by itself without the MFA flow".

-- Scott


-- 
For Consortium Member technical support, see https://urldefense.com/v3/__https://shibboleth.atlassian.net/wiki/x/ZYEpPw__;!!DZ3fjg!qox4syFdcUgD4dFLSVxNpTaXFnH3rLpq9vReFtcHNIv-FFEH4jt8jvUL6hGo4z-h6Q$ 
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net