IdP 3.2 and DuoSecurity options

[Rich Graves]

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 https://github.com/Unicon/shib-mfa-duo-auth/issues 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 github.com/duosecurity/duo_shibboleth 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 https://www.duosecurity.com/docs/shibboleth only mentions their code while https://www.duosecurity.com/company/press-releases/unicon-and-duo-security-collaborate-to-develop-multifactor-authentication-extension-for-shibboleth-3-x-idp 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.