Giving an SP the authnContextClassRef they asked for

[Cantor, Scott]

On 1/13/22, 10:33 AM, "users on behalf of Wessel, Keith" <users-bounces at shibboleth.net on behalf of kwessel at illinois.edu> wrote:

>    One related question to this: should I be setting the idp.authn.SAML.supportedPrincipals property to include
> Password, PPT and MFA principals similar to what I had set for my MFA flow before implementing the proxy?

The default for that flow is the Password methods like most of them are. The only ones that don't default that way are set via property (or you have the old XML beans declared yourself, but the SAML flow came later in 4.1 so it didn't normally appear as such a bean).

You would set it to something specific in one of two cases:

Using the flow by itself without the MFA flow telling it to run, in which case the IdP has to use it to decide whether to try to run it if it gets a request containing one of the context classes that may or may not be supported. The MFA flow does some capability checks on flows it runs but that isn't one of them, if you tell it to run something it won't care up front whether the flow supports the request or not, only at the end. So using the MFA flow as a driver circumvents the need to list anything.

Setting the default-off property to automatically add the flows "supported" Principals to the final result, which is almost unheard of with SAML proxying because the values generally have to come from, or be mapped from, the SAML assertion.

That's why it isn't usually set to anything in particular and doesn't come into play. The first case would be a lot more likely to come up than the second, if all you do is proxy everything, and you would have to tell it what to support when it comes to SPs making requests or a relying party rule.

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

-- Scott