reuse of MFA flow result for SSO

[Cantor, Scott]

> So if I understand you correctly, if you access one service that only needs a
> password authentication context, successfully generate a session, and then
> attempt to access a different service that requires an MFA authentication
> context (either directly from the SP or overridden locally), the idp will not
> simply send on the existing SSO password context but instead route you back
> through the MFA logic so you get a duo prompt?

The rule you posted is in isolation, but assuming I can infer the rest being what I would assume it is, yes, that's what happens. That isAcceptable check will fail and cause it to leave the next flow pointer set to Duo. If it doesn't fail, then the original Password result was necessarily sufficient to satisfy the SP based on what the IdP knows and it nulls out the variable to cause the flow to complete. All of that is only when the user identity isn't part of the decision. That is a much more complex case.

> * Can this user do Duo? If not, skip MFA.
> * Is this a service that doesn't need MFA? If so, skip MFA.
> * Otherwise, do MFA

Then you have to use all the ugly workarounds described to force the IdP to run the MFA rules when it normally wouldn't or they won't run and SSO just happens any time the SP's needs are satisfied by what was already done. The issue is whether the SP's rules are applicable to all users or not. If it "requires MFA except for the users it doesn't" then you are in a mess and you can't tell the IdP to really require MFA and so it will assume a Password is good enough if it gets the chance. The rule is no longer going to be outside the MFA logic, which means you have to convince the IdP to always run it, and it doesn't generally want to do that.

> The scenario that concerns me is if a user that can do MFA initially accesses a
> service for which it is not performed, then goes on to access a service for
> which it is required, that SSO would have let them in without MFA actually
> being performed. It sounds like this will just work without any extra
> configuration assuming the second service requests an MFA authentication
> context?

Only if it asks for that. If it can't, and the IdP doesn't know to do it or can't make the determination without knowing the user, then the original result will simply be reused as sufficient.

> However, if the second service is one that will optionally do MFA, then the
> user will not be prompted to do MFA and will access it via SSO unless this
> extra configuration is done to force reevaluation of the logic?

Yes.

> Are there any samples in the wiki showing how to override the requested
> authentication context for a given entity ID/relying party or list thereof? I
> guess I will need to do that for any MFA required SP that does not request it
> directly.

That is an example of one by EntityAttribute as an indirect way of identifying SPs. If you want it by specific SP, that's just RelyingPartyByName and there are certainly examples of that around.

> Then for the list of services that don't need MFA at all I could either hardcode
> them all in the MFA decision logic or use an entity attribute filter to mark
> them and then check for that tag in the logic?

You wouldn't generally check for the ones that don't, just the ones that do. I put SPs into various "groups" by sticking them in overrides and then I have scripts that actually look at the ID of the RelyingPartyConfiguration at runtime to decide which group they're in. I should be doing that with EntityAttributes, but it's the same idea.

-- Scott