MFA result reuse with Duo.

Michael A Grady mgrady at unicon.net
Wed Jan 18 16:33:27 EST 2017


> On Jan 18, 2017, at 3:16 PM, Jim Fox <fox at washington.edu> wrote:
> 
> 
> We have something related at UW.  We have an SP that requests Password authn, but for certain users (identified by group membership) they want us to require Duo as well.  I have no control over this requirement.
> 
> My solution was to replicate MFA, into 'wdmfa' (that's easier than you'd think) and assign 'wdmfa' to that SP.  Essentially they get their own 'Password'.
> 
> Jim
> 
> 
> On Wed, 18 Jan 2017, Cantor, Scott wrote:
> 
>> Date: Wed, 18 Jan 2017 13:08:24
>> From: "Cantor, Scott" <cantor.2 at osu.edu>
>> To: Shib Users <users at shibboleth.net>
>> Reply-To: Shib Users <users at shibboleth.net>
>> Subject: Re: MFA result reuse with Duo.
>> On 1/18/17, 3:56 PM, "users on behalf of O'Dowd, Josh" <users-bounces at shibboleth.net on behalf of Josh.O'Dowd at mso.umt.edu> wrote:
>> 
>>> Yes, sorry, at the time, we were very early in talks with Duo and getting Demo set up.  At that time I didn't have the
>>> current requirements that I am trying to satisfy today.  We are still in the demo/decision stages with Duo but they are
>>> getting close to a commitment, so I am getting a clearer picture of our initial use case.
>> 
>> It's not like the use case is novel but not having it in front of me to work through I didn't realize there was a gap. I don't know how best to solve at this stage, but I think it boils down to more control over reuse/SSO.
>> 
>> Right now SSO is linked to remembering previous results, but if the system tracked the results but didn't impose its own reuse logic, that might work. Even a basic "SSO or not" flag independent of the enabling of the session layer might be enough to solve it.
>> 
>> -- Scott



We had a client that wanted an example attribute-resolver script, for populating the "user attribute as to which flows apply" that you could use with our 3.x Duo plugin pre- 3.3, that would illustrate handling all the following use cases:

1.	Require Duo login for opt-in users [i] logging into the IdP (i.e., any SP).
2.	Require Duo login for all users logging into specific SPs.
3.	Require Duo login only for a certain user population [ii] logging into specific SPs.
4.	Require Duo login only for opt-in users [i] when logging into specific SPs.
5.	Opt-out [i] certain users from Use Case #3.

I had sent that to the Shib Users list, along with the sample resolver script, back in April 2016. I don't know that this client actually ended up actually implementing all these use cases. Didn't think to resend that list as comments for the 3.3 development. Not sure if you want to worry about all those, but certainly there are folks thinking about having those use cases.

--
Michael A. Grady
IAM Architect, Unicon, Inc.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20170118/8138edab/attachment.html>


More information about the users mailing list