Determining if a user has a Duo token

Richard Frovarp richard.frovarp at ndsu.edu
Tue Aug 23 15:41:42 EDT 2016


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.



More information about the users mailing list