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

[Cantor, Scott]

On 4/27/21, 9:20 AM, "users on behalf of Ullfig, Roberto Alfredo" <users-bounces at shibboleth.net on behalf of rullfig at uic.edu> wrote:

>    OK I thought that might be the case, but then that brings me back to my first question. If I have only MFA
> enabled then every service provider goes through this MFA Transition Map, right?

Barring SSO, yes.

> If I want to enable Duo for just a few SPs I asked if I should put that code here but then you said I should be
> using a relying party profile for each SP, but if MFA is the only one enabled how is that going to work?

Firstly, I said overrides, not "overrides for each SP". I would never say that. There are many ways to control behavior, and doing it per-SP is thw worst. The best is the metadata-driven configuration feature. The second best is probably a custom metadata tag/EntityAttribute and a by-tag override, and sometimes that's even the best. The worst is by a specific SP or list of SPs hardcoded into a file.

To address the main point of confusion, MFA (the flow ID) does not mean multi-factor authentication, and it was a mistake to call it that. The MFA flow is an orchestration layer for login flows that simply replaces the original IdP login selection process with a different layer that's scriptable and more capable. It should have been the original design to start with.

It doesn't do MFA itself. Combining flows like Duo, or running flows that do multi-factor alone is what produces multi-factor authentication organically.

The rules you provide are what determine how authentication is done.

You are meant to control the system's behavior by associating custom Principal objects that in some cases represent AuthnContext classes with login flows and other configuration objects such as relying party overrides, metadata tags, etc. That is less brittle and is dynamic without requiring restarts to change every detail.

The orchestration, when done properly, automatically figures out what has to happen to satisfy a request by running the isAcceptable() methods scattered around the API, principally the one hanging off the MultiFactorAuthenticationContext object which is what the examples I have provided show how to do. They simply decide whether to run flows based on whether the previous results are already sufficient to complete the request.

When isAcceptable returns true, the results that have been produced are already sufficient to meet the requirements of a request, which by implication means there's no need to do anything else. When that's done, you get step-up automatically and the amount of configuration is extremely minimal and never has to be touched.

-- Scott