Determining if a user has a Duo token

[Wessel, Keith]

You make a good point about it failing open. We don't' want everyone to be treated as non-MFA-eligible just because the API call fails. Otherwise, we might be letting folks into applications that will accept single or multifactor with a single factor when we shouldn't be.

We're already using the directory attribute to indicate MFA eligibility. Actually, we're using group membership, but that's the same thing from the perspective of the IDP. But our folks didn't want to have to keep the AD group in sync with the users who had signed up for Duo.

I think the answer, as was suggested by one of our AD guys, is a process on the AD side that will make the API call to Duo to pull back all of our users and update the AD group membership. This could be run out of cron or, to avoid lag, could be initiated by a call from our local Duo self-service/management console.

So, I think we'll stick with our AD group or directory attribute and use the API call external to the IDP.

Thanks for the info, all.

Keith


-----Original Message-----
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Richard Frovarp
Sent: Tuesday, August 23, 2016 2:42 PM
To: Shib Users <users at shibboleth.net>
Subject: Re: Determining if a user has a Duo token

On 08/23/2016 01:48 PM, Wessel, Keith wrote:
> Wondered if anyone had any suggestions or solutions for what I was approached with yesterday. Is there a way for the IDP to make some API call to Duo to see if a user has set up a token? I've thought about writing a custom data connector to handle this, but that seems like a lot of work for a small task, and I'm not even sure if such an API call exists. All of the Duo code I've seen has to do with handing off a signed request to the init method of their Javascript and letting it display either an i-frame or an error message, but no way to make decisions based on those results.
>
> We've been, thus far, using an AD group to indicate that a user is Duo eligible, meaning that they've set up their token. If they set up the token, they're in the group.
>
> Now that we're opening up MFA to all staff and faculty, we'd like to get away from that model if we can. That's a lot of people in one group.
>
> For services that request Duo from our IDP via our Duo authentication context, this isn't a problem. If the user hasn't yet set up a token, they can't get in. Where it's a problem is for services that request Duo followed by password as a fallback. If we simply key Duo eligibility off of the staff/faculty affiliation, they'll always get the Duo i-frame even if they haven't set up a Duo profile.
>
> We'd like to, instead of using the staff/faculty affiliation as an indicator for Duo eligibility, make the API call to see if they have a profile. If they don't, we can either send them through with password if the service requested that context as a 2nd option or fail if the service requires Duo.
>
> Any thoughts? Or do I need to tell them we're better off sticking with the AD group which can be programmatically maintined by our Duo enrolement process?
>
> Thanks,
> Keith
>
The Duo Shibboleth integration does this for you. The one downside is if 
you allow for split usage. If you allow people to log in without MFA if 
they don't have MFA, but require MFA if they have MFA. By default their 
code would likely fail open, so it would appear during any communication 
issues with Duo that none of your users have a token. I would put it on 
a attribute for the user in AD. That way you have something local to 
look against in case your connection to Duo is interrupted. Carlton's 
modification of the Duo one does this with a web call, and I think 
Unicon's does this against an assurance attribute in AD.

-- 
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net