Duo Security Authentication and IdPv3

Jonathan Johnson jsjohnson at unicon.net
Wed Apr 29 15:05:25 EDT 2015


Been working on getting Duo security integrated into a v3 build, and have been pretty successful. Have also been looking a bit at how the flows work to try to fill some of the gaps for the MCB and possibly some further use cases.

So, the implementation so far:

In my `idp.properties` file, I’ve set `idp.authn.flows=Password|Duo`, `idp.authn.flows.initial=Password`, `idp.uathn.resolveAttribute=eduPersonAssurance`, and various Duo specific properties. `eduPersonAssurance` is a generated value from a java class that I have out there (the implementation that I am working on for it is calling a web service with principal name, ip address, and SP entityId to get back a list of step-up requirements, if any). Everything works, as expected (at least from my understanding of the default flows).

My notes:

1. Canonicalization happens after each authentication. This was unexpected at first until I realized that the both `authn` and `authn-initial` are calling it.
2. For a similar reason, subjects are getting stored to the session (in my case the cookie) after each authentication
3. Only the second authen context is being reported back to the SP. Not such a big deal right now, but something I will have to come back to later.

Given these, would it be better, then, to just write a single auth handler that has a tighter loop and handles these step ups? I can sort of mitigate what’s going on right now with just the one step up, but if I get to where I need another (say, adding a biometric to the mix), I might need a little bit more than is available currently.

On a side note, what are your feelings about adding something like the following to `web.xml` in the distribution:

```
...
    <context-param>
        <param-name>contextConfigLocation</param-name>
        <param-value>
            ${idp.home}/system/conf/global-system.xml
            classpath*:/META-INF/shib/conf/global.xml
        </param-value>
    </context-param>
...
    <servlet>
        <servlet-name>idp</servlet-name>
        <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
        <init-param>
            <param-name>contextConfigLocation</param-name>
            <param-value>${idp.home}/system/conf/mvc-beans.xml ${idp.home}/system/conf/webflow-config.xml classpath*:/META-INF/shib/conf/webflow-config.xml</param-value>
        </init-param>
        <init-param>
            <param-name>contextClass</param-name>
            <param-value>net.shibboleth.ext.spring.context.DeferPlaceholderFileSystemXmlWebApplicationContext</param-value>
        </init-param>
        <load-on-startup>1</load-on-startup>
    </servlet>
...
```

Allowing spring to pull from the classpath has allowed me to have a drop in jar that contains all the configuration needed for the authentication handler and flows without having a lot of other configuration to do in the system itself.

It was suggested that I might join the dev call some week to go over some of this with you all, perhaps to go over some of this.

Hope this wall of text doesn’t make anyone too bored :) Thanks

-Jj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20150429/e5d5a987/attachment.html>


More information about the dev mailing list