optional use of two-factor for Duo login handler

[Russell Beall]

Hi Bryan,

I have heard of the project and I knew it was capable of being programmed to perform the necessary functions. I even saw a demonstration at Advance CAMP. 

I did not get the idea that it was simple enough but I haven't researched it nearly enough to say much. I was shooting for a simple enhancement to the Duo plugin in particular, to make it more readily deployable and more ready for experimentation without overriding the institutional default authentication.  

This is not for USC because I already have a very customized login handler where I would have to import this functionality separately. This is a collaboration with David Bantz from Alaska and the folks at Duo. 

If the MCB will easily do what I've outlined then I've wasted my time. Not much time luckily because it only took me a few evenings to code. I don't quite think I've wasted my time because my enhancement may still be useful in certain cases. 

At least I have the clear answer to my request for advice that the MCB warrants more study with multiple people recommending it as the direction the community is going in this area. 

Russ.
(iPhone)


> On Nov 27, 2013, at 3:31 PM, "Bryan E. Wooten" <bryan.wooten at utah.edu> wrote:
> 
> Sigh. I guess the whole NSTIC / MFA / LOA grant message is not being
> communicated?
> 
> Hell, I gave a presentation with bbellina at usc.edu <bbellina at usc.edu> at
> Educause in October.
> 
> Happy Thanksgiving all,
> 
> Bryan
> 
>> On 11/27/13 4:19 PM, "Russell Beall" <beall at usc.edu> 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
> 
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net