reuse of MFA flow result for SSO

[Paul B. Henson]

> From: Cantor, Scott
> Sent: Monday, March 19, 2018 5:55 PM
> 
> 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.

Color me confused again, sorry :(. I was testing with the basic MFA check:

                nextFlow = "authn/Duo";
                authCtx = input.getSubcontext("net.shibboleth.idp.authn.context.AuthenticationContext");
                mfaCtx = authCtx.getSubcontext("net.shibboleth.idp.authn.context.MultiFactorAuthenticationContext");
                if (mfaCtx.isAcceptable()) {
                        nextFlow = null;
                }
                nextFlow;

using one service that doesn't request a specific authentication context and one service that "requires" MFA. My assumption was that it actually requested the MFA authentication context, but I could be mistaken and it just denies access on the SP side if you show up without one.

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?

> as awkward to do that. But unless your rules depend on more than just the
> SP, none of that is relevant.

Tentatively, our logic is going to be roughly:

* 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

There will be two types of user, those that can do duo and those that can't; and three types of services, ones which can be accessed without MFA, ones that will use MFA if available but let a user in otherwise if not, and those that strictly require MFA and will fail if a user cannot do it.

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?

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?

> Tag?

I was looking at this example in the wiki:

<bean parent="RelyingPartyByTag">
    <constructor-arg name="candidates">
        <list>
            <bean parent="TagCandidate" c:name="http://macedir.org/entity-category"
                p:values="http://example.org/mfa-candidate"/>
        </list>
    </constructor-arg>

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.

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?

https://wiki.shibboleth.net/confluence/display/IDP30/EntityAttributesFilter

Thanks for the help and clarification.

--
Paul B. Henson  |  (909) 979-6361  |  http://www.cpp.edu/~henson/
Operating Systems and Network Analyst  |  henson at cpp.edu
California State Polytechnic University  |  Pomona CA 91768