optional use of two-factor for Duo login handler

[Russell Beall]

Hi Michael,

Thanks for all the references and links. I was aware of the MFA initiative (see last message) but obviously not deeply enough. 

I have some more homework to do now. :-)

Russ.
(iPhone)


> On Nov 27, 2013, at 4:34 PM, "Michael A Grady" <mgrady at unicon.net> 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