Step-up MFA

[Andrew Morgan]

Keith,

Make sure you have p:reuseCondition="false" set for the authn/MFA bean in 
conf/authn/general-authn.xml.  This makes it re-run the MFA logic on each 
request.  In v3.3, this was controlled by idp.authn.favorSSO in 
idp.properties.  It's possible you had it working in v3.3 but it changed 
in the upgrade to v3.4...

Thanks,
 	Andy


On Mon, 13 May 2019, Wessel, Keith wrote:

> Thanks, Scott. I was certain I had this logic right, though, and I could swear it used to work. From what I can tell now that I've added logging, the MFA flow isn't running for the second SP -- the one that isn't requesting any specific contexts and thus should force me to use MFA in my script. But I see no logs. Is it simply a matter of telling it to re-run the flow? If so, how?
>
> Or is it time to rethink my logic? We're using MFA for everyone for any SP that explicitly requests it. For faculty, staff and grad students plus opt-in undergrads, we're using it for all SPs except for a couple of exempted ones.
>
> My MFA script relies on the assurance attribute which checks to see if the user is in a require population, but also on another attribute called allowDuoOnly which returns true except for the exempted SPs.
>
> It's already more complex than I'd like, and I'd welcome suggestions on how to simplify it.
>
> Keith
>
>
> -----Original Message-----
> From: users <users-bounces at shibboleth.net> On Behalf Of Cantor, Scott
> Sent: Monday, May 13, 2019 4:40 PM
> To: Shib Users <users at shibboleth.net>
> Subject: Re: Step-up MFA
>
> On 5/13/19, 3:47 PM, "users on behalf of Wessel, Keith" <users-bounces at shibboleth.net on behalf of kwessel at illinois.edu> wrote:
>
>> I was informed this morning that going first to the exempted SP then to any other SP lets you in to both without step-up. > Not good, obviously.
>
> That's not possible unless the system isn't being told that the "other SP" actually requires MFA. Without doing that, you're very open to holes like this without a lot of careful workarounds. When it's not all or nothing, it's best to configure the SPs on the IdP end as requiring MFA and use your MFA logic where necessary to "clear" that status at runtime in the event that a user qualifies as not requiring it, that way you default to a safe result.
>
>> Am I correct that an authentication request on an existing IdP session will cause the IdP to evaluate the requested
>> authentication contexts against those the user has already satisfied? And if one has not already been satisfied, the IdP
>> will go through the MFA authn flow again to satisfy a requested context?
>
> Yes, so what you describe is only possible if the new SP isn't treated as requiring anything special, or if the original result for the exempt SP was configured claiming it did the second factor when it didn't.
>
>> And at that time, the MFA script will resolve any attributes coded into it to resolve (like the eduPersonAssurance
>> attribute) along with any dependent attributes. I want to make sure that my issue isn't attribute caching or even the
>> MFA flow not running at all.
>
> All of that is possible too, but when you get the basics wrong, it's going to break in some cases no matter what.
>
>> I've checked over my logic in my MFA script and my attribute definitions and can't find any reasons why this wouldn't be
>> working, and I know it did in the past. So, I thought I'd confirm how things _should_ work for step-up.
>
> It can work any way imaginable, that's not really a simple question. It will bypass the MFA flow entirely if it thinks it's allowed to do that and isn't told not to but that depends on what the SP requires and what the result from before claims.
>
> I never remember the exact case that comes up that requires workarounds like marking the MFA flow non-reusable, which is what forces the flow/scripts to run each time. I think honestly that's only a problem when you don't use the pattern I mentioned...if the SP *might* require MFA, tell the IdP it does, and then undo that in the logic. That's not hard to do and it's quite safe.
>
> -- Scott
>
>
> -- 
> For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
> -- 
> For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
>