SP Requiring/Requesting MFA (was Re: Customizing Second Factor Configuration in mfa-authn-config.xml)

[Cantor, Scott]

On 5/14/21, 4:05 PM, "users on behalf of Ullfig, Roberto Alfredo" <users-bounces at shibboleth.net on behalf of rullfig at uic.edu> wrote:

>    One:
>
>    1. SP sends authn request (MFA or Password) to IDP
>    2. IDP rejects authn request
>    3. There is no SSO

Why would it reject it? That looks perfectly normal, and SSO has nothing to do with the first request, it's a description of the behavior on later requests that depends on what happened before.

The rest is similar, I don't understand what these scenarios mean so I don't know what I'm supposed to tell you about them. Are they correct? Maybe? I don't know. In many cases, there is no "correct" or "incorrect", just behavior you have to decide you want or don't want. Within the limits of the standard anyway.

> ITrust Federation Manager for some reason is sending BOTH MFA and Password authn requests so what's used
> by the IDP is undefined but it looks like our IDP is just using the last one sent which is Password because that's
> what's being used.

If you mean "last" in the sense of the order they appear in the message...requesting both context classes like that means "either of these is fine". The behavior implemented by the examples I have built is that if the existing session contains results that satisfy "Password", then there's nothing more to do and SSO occurs (no additional prompt, no additional factor, etc.).

If you want to require MFA, you don't say "hey, Password's fine with me". Why that seems to surprise people is not clear, but that's what the standard allows. Exact matching *is* ordered, but that only makes sense when there are disrcete options involved and neither is already in place from a previous request.

> The authn request always has priority over anything that we have configured for that SP. If we accept the authn
> request the IDP must do what the SP requests. If we reject it, there is no SSO.

Conventionally "no SSO" tends to mean "authentication happens again, instead of SSO" when people use that phrasing. So my answer is that if you "reject it" if you mean with the disallowedFeatures option, no, you don't get "SSO" or "not SSO", you get an error. "No SSO" isn't how I would phrase that. I suspect that's why I'm lost with your scenario descriptions, the terms are just foreign to how I would use them.

You have two options with SPs that include RequestedAuthnContext elements. You can accept the request and satisfy It (or be unable to and fail the request), or you can set the option that blocks requests that contain that element and fail up front. Not fail SSO, fail *period*. You get an error.

-- Scott