IdP 3.2 and DuoSecurity options

Rich Graves rgraves at
Thu Dec 31 16:21:41 EST 2015

Obviously you're both right, thanks. My first naive attempt to perform the Unicon+UChicago classpath/flow/assurance modifications failed; I'm not sure why. I saw at that they were going to refactor for IdP 3.2, and came to this list for a sanity check. That sanity check came back negative (on my part). Thanks to you both for the corrections.

In the meantime, I got Duo's independently (?) developed shib v3 plugin "working" with IdP 3.2.1, with a hack to check my LDAP "Assurance" property from within their Java code (rather than idp.authn.resolveAttribute). From my naive standpoint this seems "simpler" than the more flexible Unicon+UChicago approach. It also appears to work better with a dumb Ellucian WebAdvisor SP that will only accept the exact authn context urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport. With the duosecurity/duo_shibboleth plugin, I get to "lie" and tell Ellucian that I used passwords alone, but in fact used paswords+Duo.

If anyone sees red flags in the approach, I'll take another crack at the Unicon+UChicago implementation, but I think I could be happy where I am.

It's a bit odd that only mentions their code while only mentions Unicon's "competing" code, but this wouldn't be the first time that engineers and PR people were not on the same page.

More information about the users mailing list