Using Duo for per-SP-opt-in

[David Langenberg]

> On Jan 29, 2016, at 10:08 AM, Rich Graves <rgraves at carleton.edu> wrote:
> 
>> https://wiki.shibboleth.net/confluence/x/ZABlAQ
> 
> Thanks for filling in the gaps in their docs! I think I see the step that I missed a month ago. If you can find the time, you might want to update David's "Replicating Multi-Context Broker Functionality" page or send a pull request to Unicon.
> 
> I agree that for your SP-driven use case you need to use the Unicon code. FWIW, the reasons I am still using the Duo version are
> 
> - The Duo code checks user enrollment and has the option of failing open if Duo is unavailable (though Unicon has already started adding this to their "wip" branch at github)
> - The learning curve
> - I have a hack for Duo opt-in at my end (though this only works for user-driven, not SP-driven): https://github.com/carleton/duo_shibboleth/commit/b649e84861d777f1bfbb2e415c3cb3477bfa3107
> - As Scott mentioned, there is no standard AuthnContextClass to use. There is at least one Ellucian SP important to us, one for which we definitely want to use Duo, that specifically demands urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport and fails when given our private Duo class (using the IdPv2 MCB). It's possible that we could work around this, but see learning curve. Because it hooks elsewhere, the Duo module happens not to have this problem.

Strange, we have this working (SP demands PPT, but we make the user do Duo anyway & tell the SP it was PPT).  Take another look at your authn-context-comparison setup?

Dave


--
David Langenberg
Identity & Access Management Architect
The University of Chicago