reuse of MFA flow result for SSO

Cantor, Scott cantor.2 at
Wed Mar 21 15:28:38 EDT 2018

> Hmm, but if I override the requested AuthenticationContext for that specific
> relying party in the config, that is the same as if it had actually asked for it, so
> an existing password only session would be insufficient and the user would
> get rerouted through the MFA logic?

Yes, that's conceptually the same thing. Overriding the fairly misnamed "defaultAuthenticationMethods" property just mocks up the same context object that a RequestedAuthnContext in a SAML request turns into, the only difference is that a SAML request has all the matching operator types while the relying party setting is always "exact". The rest of the behavior is identical regardless of why it got created.

> Tentatively I think the list of services that just don't want to do MFA at all will
> be much shorter than the ones that will optionally do MFA.

In that case I guess it's just reversed then, but same means of doing it essentially.

> Thanks much for the help, sorry if I'm not picking things up as quick as I
> should be.

I'm hoping the mechanics of what it's doing are clear, but the workarounds to fool it into not doing what it normally does are just inherently ugly.

The 3.4 change is just a feature added that lets you configure a login flow to never have its results reused. That isn't that useful for most methods, but the MFA flow is a special beast and since it will internally reuse the "subresults" it generates, it is often sensible to just not reuse its result as a whole, and let it decide what to do.

So you just flip a flag and you know that no matter what happens, your rules run. Then it's up to you to tell it what to try and why, and the rest is just brute force scripting.

It's rare that once you're down in that layer that you wouldn't want it just reusing factors for you, if we exclude special cases like ForceAuthn, which it will automatically detect anyway.

So the logic might start out always running authn/Password, and you know that won't cause extra prompting but your rules can just be written to control the right sequence to use or when to bypass things and not worry much about how it ends up looking. It should do what you expect once the rules are running. It's getting them to run that becomes complex right now because the 3.3 code always tries to reuse results of login flows, bypassing the whole thing.

-- Scott

More information about the users mailing list