IDP 3.3 MFA flow -- working example

[Cantor, Scott]

> I'd like to see a working example of duo 2 factor
> authentication in the IDP 3.3 MFA flow.

I posted mine at the end, which I built by stripping the attribute logic out of the delivered example. It is the most bare-bones case, I believe, other than possibly forcing Duo for all cases.

All I did to the file delivered was s/IPAddress/Password, s/Password/Duo, strip out the extra logic in the script I didn't need, and then get the right supportedPrincipals defined in general-authn.xml

> We then revised the flow to make duo optional based on
> a specified attribute.

That's the general logic the example I provided in 3.3 is demonstrating, how to look up an attribute and then do something based on it between steps. I need to fix the username-determining bug Keith Wessell found, and once I do that I'll post the updated example in the documentation. It doesn't fundamentally change the example, just makes the username step a bit uglier.

> Then, we used the same logic used in that flow to include
> optional RSA and yubikey 2 factor authentication,
> based on user based or SP criteria.
> The RSA flow includes handling of NEW_PIN_REQUIRED
> and NEXT_CODE_REQUIRED.

The intention is that you build the flows to do those things *in isolation* and then use the script logic to decide when they run. That's all.

I'd be a little curious how you managed that RSA part, I never saw any way to handle those modes with the Java SDK from RSA. It looked like it would take holding connections to SecurID open across web requests, which is a non-starter to me.

> I note the above, because, we have multiple 2 factor
> authentication flows working using webflows and subflows.
> We have moved that functionality to IDP 3.3.

Of course it should continue to work as is (without moving it to the MFA flow).

> We are now working to use the IDP 3.3 MFA implementation.
> And are having trouble figuring out how to do that.

I guess I don't really grasp how you could do all that with the older version, including doing your own webflows, but can't follow that example. Maybe you could explain better what it is that you don't understand.

-- Scott

    <util:map id="shibboleth.authn.MFA.TransitionMap">
        <!-- First rule runs the Password login flow. -->
        <entry key="">
            <bean parent="shibboleth.authn.MFA.Transition" p:nextFlow="authn/Password" />
        </entry>

        <!--
        Second rule runs a function if Password succeeds, to determine whether an additional
        factor is required.
        -->
        <entry key="authn/Password">
            <bean parent="shibboleth.authn.MFA.Transition" p:nextFlowStrategy-ref="checkSecondFactor" />
        </entry>

        <!-- An implicit final rule will return whatever the final flow returns. -->
    </util:map>

    <!-- Example script to see if second factor is required. -->
    <bean id="checkSecondFactor" parent="shibboleth.ContextFunctions.Scripted" factory-method="inlineScript">
        <constructor-arg>
            <value>
            <![CDATA[
                nextFlow = "authn/Duo";

                // Go to second factor if we have to.
                authCtx = input.getSubcontext("net.shibboleth.idp.authn.context.AuthenticationContext");
                mfaCtx = authCtx.getSubcontext("net.shibboleth.idp.authn.context.MultiFactorAuthenticationContext");
                if (mfaCtx.isAcceptable()) {
                    nextFlow = null;
                }

                nextFlow;   // pass control to second factor or end with the first
            ]]>
            </value>
        </constructor-arg>
    </bean>