reuse of MFA flow result for SSO

[Cantor, Scott]

On 3/19/18, 8:38 PM, "users on behalf of Paul B. Henson" <users-bounces at shibboleth.net on behalf of henson at cpp.edu> wrote:

> However, it seems that what does happen is if they have successfully gone through the MFA flow at all, even if just
> asked for a password, they do SSO on all following requests regardless of the authentication context a given SP requests,
> so they get sent to that SP and told to go away by it because they didn't do MFA.

That is a function of what you do in your MFA ruleset, but in all cases if the SP really asks for X, and the final result doesn't satisfy X, the IdP returns a failure to the SP. The pathological defaults and examples all do step-up automatically provided the SP is the determinant. That's the case whether it asks itself or the relying-party settings override it, the rest of the behavior is the same and it simply detects what it has to do.
 
> Looking at the documentation https://wiki.shibboleth.net/confluence/display/IDP30/MultiFactorAuthnConfiguration
> entitled "Reuse of the Entire authn/MFA Flow Result" which seems to discuss what I'm talking about, and while I haven't
> tested it it sounds like if I changed the idp.authn.favorSSO property and added a defaultAuthenticationMethods for the
> SP that demands MFA, it would do what I want?

That's about dealing with cases that depend on user-specific logic that has to execute in the MFA rules to know what to do. If the SP asks for X, and the result doesn't satisfy X, the MFA logic will run, because SSO can't be done and it knows it needs to run that logic again.

But if the SP asks for nothing, then any previous result will be valid, and if the rule is "it might depend who the user is and the time of day and the phase of the moon", then the IdP doesn't generally deal with that well and has to be fooled into running the MFA logic again. I patched that for 3.4 so that it's not as awkward to do that. But unless your rules depend on more than just the SP, none of that is relevant.

> However, that seems a bit complicated and manually intensive to have to maintain a local list of "MFA required" SPs
> rather than simply relying on them to request the authentication context they actually want.

That's orthogonal. If they don't ask, and most can't, then you're maintaining a list. What else could be done? How else would it know?

> Is there some way to do this relying upon the requested authentication context for the tag rather than an explicit entity
> -category or list of SPs?

Tag?

-- Scott