optional use of two-factor for Duo login handler

[Russell Beall]

Hi Michael, and others interested in this subject,

It took me a while to get back to this through the holidays and a major installation...  I have now read through these references and I figured out how the Multi-Context Broker can be used to perform the functions I wrote into my customization of the Duo plugin.  Essentially what I wrote into the Duo plugin was a microcosm of the functionality available in the Multi-Context Broker.

I suppose the key question now is: has somebody already coded the login submodule required to invoke Duo as a component of the Multi-Context Broker login handler?

For demonstration purposes, my customization might be very handy for those wanting to try out Duo, but it seems pretty clear that in the long run, using the MCB would be the way to fully productionalize such an installation, especially where there will be more authentication contexts and methods desired.

Regards,
Russ.

On Nov 27, 2013, at 4:34 PM, Michael A Grady wrote:

> Russ, I take it you are unawares of the work on the Assurance & MFA Enhancements to the Shib IdP, which had an RFP in the spring:
> 
> https://spaces.internet2.edu/x/DYI_Ag
> 
> and the resulting code implementing those enhancements, and the multi-context broker, is now in final acceptance testing:
> 
> https://spaces.internet2.edu/x/LgFtAg
> https://wiki.shibboleth.net/confluence/display/SHIB2/Multi-Context+Broker
> 
> You might also want to take a look at the work of the MFA Cohortium:
> 
> https://spaces.internet2.edu/display/mfacohortium
> 
> particularly documents like:
> Alternative Strategies When Multi-Factor Tokens Are Not Available
>  https://spaces.internet2.edu/x/RABtAg
> 
> and the slides from U Penn's deployment of opt-in (not with Shib though, but good to consider from a design perspective)
> https://spaces.internet2.edu/download/attachments/36703456/UniversityPennTwoFactorDeployment.pdf
> 
> On Nov 27, 2013, at 5:19 PM, Russell Beall wrote:
> 
>> Hi all,
>> 
>> I am working on a formal and generic customization of the Duo login handler to make it configurable for optional invocation of the second factor.  The conditional invocation will be based on two possible configuration options -- a custom authentication method designation or a user attribute having a certain value.
>> 
>> I am looking for feedback on my design as well as responses to gauge the level of interest in the community.
>> 
>> The key reason for this upgrade is that the default handler is designed to always invoke two-factor for every request from any source.  This seems untenable for any institution that already has an infrastructure of more than a few (let alone hundreds) of service providers already in service.  Suddenly requiring two-factor for the entire set would be a problem.
>> 
>> The upgrade I am building offers the following features:
>> 
>> 1.  A user attribute name can be configured as well as a value to look for (or "*" for any value), and if that value appears in the attribute set of the principal, then the user has opted-in and two-factor will be used for that user, and not for others.
>> 
>> 2.  The requested authentication method can control the use of two-factor so that if a service is configured to request the two-factor method, all users of that service will be challenged for two-factor.  This is of course for sensitive applications.
>> 
>> 3.  The single factor authentication method can be specified separately from the two-factor authentication method.  When only a single factor was used, that method is reported, and when two-factor is used, that method is reported UNLESS the service provider specifically requested the method designated as single factor.  In that case the single-factor method is reported anyway to avoid an error.  That should be sufficiently correct since the two-factor method is a superset of the single-factor usage, but this is a point where I am looking for confirmation or advice.
>> 
>> 4.  All of the conditional features are enabled only if a boolean flag is set on the handler config, otherwise the handler behaves exactly as it is currently coded and published by the Duo team on GitHub.
>> 
>> Does this seem like a decent feature set that would be useful to many institutions?
>> 
>> Is there anything that should be added (anything that doesn't significantly increase complexity)?
>> 
>> Any other advice?
>> 
>> Thanks,
>> Russ.
>> 
>> --
>> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
> 
> 
> --
> Michael A. Grady
> Senior IAM Consultant, Unicon, Inc.
> 
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net