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

[Ullfig, Roberto Alfredo]

>                <bean parent="shibboleth.authn.MFA.Transition" p:nextFlow="authn/RemoteUser" />

"i.e there is no way you should have RemoteUser enabled, because you do not want the IdP running it by itself; the MFA logic already runs it when required."

I don't understand this response. We use RemoteUser instead of Password. The original example uses IPAddress and Password and there's mention of replacing this with Password and Duo - why would we not use RemoteUser and Duo then?

---
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: Monday, April 26, 2021 12:47 PM
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/26/21, 1:24 PM, "users on behalf of Ullfig, Roberto Alfredo" <users-bounces at shibboleth.net on behalf of rullfig at uic.edu> wrote:

>    OK then, to NOT do this globally, I define the supported authn in relying-party.xml under
> DefaultRelyingParty? Here are some of the important bits:

The DefaultRelyingParty settings are global, overrides are non-global, as are metadata-driven settings when that's done in place of putting them in the central file.

>    idp.authn.flows= RemoteUser|MFA

As the documentation notes, MFA generally stands alone. If it's enabled, nothing else generally is, or at least nothing that it directly controls/directs the use of. I doubt very seriously you want both enabled, and that will do very surprising things at times, if not outright broken ones.

>                <bean parent="shibboleth.authn.MFA.Transition" p:nextFlow="authn/RemoteUser" />

i.e there is no way you should have RemoteUser enabled, because you do not want the IdP running it by itself; the MFA logic already runs it when required.

>    I still have the same issue with the SP requesting mfa (the one I earlier posted the authn request) as it is here
> - in this case mfa is done. When I try to force it to Password with SAML2.SSO.FEATURE_AUTHNCONTEXT I get:

You didn't indicate what the issue was originally, but no, you can't do that globally without issues. If you try and globally block requests like that, you're going to break stuff.

If you explicitly enable MFA for some SP using the IdP to do it, then by definition you know it shouldn't be requesting anything and it's safe to block the feature for that SP. Globally? No, that doesn't work.

You can, at best, audit everything over time, find all the systems that are requesting something and either get them to stop or create an override that's inverted (every SP *but* the outliers).

Until that point, enabling MFA would have to be a per-SP setting, or handled more effectively, a metadata-driven setting using a tag attached to the metadata. Or literally two metadata-driven settings to actually control the defaultAuthenticationMethods and disallowedFeatures settings from metadata, which is what I do personally.

-- 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%7C87a41b5811544639441508d908db6137%7Ce202cd477a564baa99e3e3b71a7c77dd%7C0%7C0%7C637550560579381041%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=4B%2F47n0j9zjjYYq0JjkLtdBkSzF6hh95nl1Dc9qSU54%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/20210426/0bfb440e/attachment.htm>