cantor.2 at osu.edu
Mon May 13 17:39:53 EDT 2019
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.
More information about the users