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

[Ullfig, Roberto Alfredo]

Is this an accurate summation of MFA/Password selection?

The attacker (that knows the password) can send a non-MFA Authn request (like Password) to the IDP and the IDP must accept it or reject it. If accepted, the attacker is in without MFA (Scenario Three below), if rejected SSO just breaks (Scenario One below).

scenarios:

One:

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

Two:

  1.  SP sends authn (MFA) request to IDP
  2.  IDP accepts authn request
  3.  SSO with MFA

Three:

  1.  SP sends authn (Password) request to IDP
  2.  IDP accepts authn request
  3.  SSO without MFA

Four

  1.  SP does NOT send authn request to IDP
  2.  IDP does whatever it wants (Password or MFA) - this is when we can force it to MFA

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.

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.

Finally, Scenario Four is not the best solution, the better solution is to control MFA via metadata.


---
Roberto Ullfig - rullfig at uic.edu
Systems Administrator
Enterprise Applications & Services | Technology Solutions
University of Illinois - Chicago
________________________________
From: users <users-bounces at shibboleth.net> on behalf of Cantor, Scott <cantor.2 at osu.edu>
Sent: Tuesday, April 27, 2021 8:53 AM
To: Shib Users <users at shibboleth.net>
Subject: Re: SP Requiring/Requesting MFA (was Re: Customizing Second Factor Configuration in mfa-authn-config.xml)

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


--
For Consortium Member technical support, see https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.shibboleth.net%2Fconfluence%2Fx%2FcoFAAg&data=04%7C01%7Crullfig%40uic.edu%7C88ba1b4203e64625074408d90983e5c8%7Ce202cd477a564baa99e3e3b71a7c77dd%7C0%7C0%7C637551284374420403%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=QY%2BpX7CGWRahbQcGswjKMknMJzEWIZNQS93pwRz%2Bf4o%3D&reserved=0
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20210514/dbe41dc2/attachment.htm>