IDP 3.3 MFA flow -- working example

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

IDP 3.3 MFA flow -- working example

Joe Edwards

Hello again,

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

We were able to get duo 2 factor authentication working,
in <<less than one hour, in IDP 3.1 with duo's documentation.

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

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.

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.

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

I'd appreciate a working example of duo 2 factor
authentication, or analogous 2 factor authentication,
that we can use to get our IDP working with the
MultiFactorAuthnConfiguration.

Joe Edwards
UWMC, ITS
... --- ...
--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: IDP 3.3 MFA flow -- working example

Cantor, Scott E.
> 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>
--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: IDP 3.3 MFA flow -- working example

Joe Edwards

On Mon, 12 Dec 2016, Cantor, Scott wrote:

>> 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.
> .....snip
>
> 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.

After password authentication....

We use a com.rsa.authagent.authapi.AuthSession.

<evaluate
expression="our.package.shibboleth.auth.rsaSession.getRsaSession()"
result="flowScope.rsaAuthSession" />

The rsa session is then passed to our rsaAuth class:
  //check the passcode entered
  authStatus = session.check(userId, passcode);

which deals with the result:
  switch (authStatus) {
   case AuthSession.ACCESS_OK:
   case AuthSession.NEW_PIN_REQUIRED:
   case AuthSession.NEXT_CODE_REQUIRED:

the user sees the appropriate page:
  <transition on="ACCESS_OK" to="cleanup" />
  <transition on="ERROR"     to="RsaErrTwoFactorPage" />
  <transition on="NEW_PIN"   to="RsaNewPinPage" />
  <transition on="NEXT_CODE" to="RsaNextTokenPage" />

The rsa session enables the user to submit the NEXT_CODE.

  authStatus = session.next(nextcode);
   case AuthSession.ACCESS_OK
   case AuthSession.ACCESS_DENIED
   case AuthSession.NEXT_CODE_BAD

- Joe
--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: IDP 3.3 MFA flow -- working example

Cantor, Scott E.
On 12/12/16, 7:02 PM, "users on behalf of Joe Edwards" <[hidden email] on behalf of [hidden email]> wrote:

>    We use a com.rsa.authagent.authapi.AuthSession.
>    
>    <evaluate
>    expression="our.package.shibboleth.auth.rsaSession.getRsaSession()"
>    result="flowScope.rsaAuthSession" />

I guess I never tried it, but I figured orphaned sessions and delays in submitting the follow up would cause problems with the tokens. I assumed it locked them up in some way.

-- Scott
   

--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: IDP 3.3 MFA flow -- working example

Joe Edwards
In reply to this post by Cantor, Scott E.

On Mon, 12 Dec 2016, Cantor, Scott wrote:
> 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.

The primary cause of the problem I have is the complexity
of shibboleth. The property that allows me to do what I want
gets in the way of figuring out how to do it.

After I realized that I had to modify 3 files to enable MFA,
I got MFA working.

I used your example from the email to revise
conf/authn/mfa-authn-config.xml and your helpful
AuthenticationConfiguration docs to figure out what
I had to revise in authn/general-authn.xml.

The last step was realizing that I had to include
MFA in idp.properties:idp.authn.flows to make it
available.

Thanks again, Joe
--
To unsubscribe from this list send an email to [hidden email]