Giving an SP the authnContextClassRef they asked for

[Wessel, Keith]

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