Giving an SP the authnContextClassRef they asked for

Wessel, Keith kwessel at
Thu Jan 13 15:57:24 UTC 2022

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.


-----Original Message-----
From: users <users-bounces at> On Behalf Of Cantor, Scott
Sent: Thursday, January 13, 2022 9:51 AM
To: Shib Users <users at>
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 on behalf of cantor.2 at> 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;!!DZ3fjg!qox4syFdcUgD4dFLSVxNpTaXFnH3rLpq9vReFtcHNIv-FFEH4jt8jvUL6hGo4z-h6Q$ 
To unsubscribe from this list send an email to users-unsubscribe at

More information about the users mailing list