optional use of two-factor for Duo login handler

[Bryan E. Wooten]

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