Device Enrollment Screen for Duo

Karla Borecky kborecky at smith.edu
Mon Sep 17 09:55:28 EDT 2018


For our Duo rollout, I wrote a php program for people to sign up for Duo.
They have to re-auth through shibboleth, and then I present them with a
(brief) explanation of what is going to happen. Once they agree, it puts
them in the synched Duo windows group. It used to then tell them
approximately when they could expect to see the Duo device registration
kick in ('later this morning', 'tomorrow morning after xxx'), but now (with
help from a colleague) the program adds them immediately using the Duo API.
They log in again and see the initial device registration process.

As Nate said, I think Duo's onscreen guides are really pretty good. In my
initial description screen, I emphasized that folks should set up more than
one device (mentioning office phone as a possibility) because I think
that's important. But otherwise, it seems pretty self-explanatory. Our
support folks did have workshops for groups of people to do this process
with guidance as well, for those who wanted that.

I think one point of confusion here was Duo's described "self-enrollment,"
which sounds like you can decide to start using Duo using some onscreen Duo
process. This is not really the case (unless something has changed.) You
are either in a Duo group or you're not. This is why I wrote the program as
an interface so that people could decide when they were ready to use it.

So, you might want to just look at the Duo API to see if that can help you.
It might be easier than hacking the other stuff. I realize this doesn't go
with the group-by-group process you were describing, but perhaps it might
give you some ideas at least.

Hope this helps -
Karla B

On Mon, Sep 17, 2018 at 1:39 AM Nate Klingenstein <ndk at sudonym.me> wrote:

> Nanda,
>
> It's not totally clear what your desired workflow is to me.  Does
> 2.Continue simply mean the user is authenticated successfully and passed
> along to the SP without any second factor but just the notice page, or must
> they complete the device enrollment process and can then proceed to the SP?
>
> If it's the latter, Duo offers inline self-enrollment and personal device
> management built-in if it's enabled in your Duo configuration.  I've found
> users are able to navigate the interface, especially with the help of Duo's
> guide.  You can fairly easily skin the Duo page in
> /opt/shibboleth-idp/views, but not the iframe portion.  You could add a
> link to the guide.
>
> https://guide.duo.com/add-device
>
> It's somewhat less secure than an assigned roll-out because you're relying
> on the first set of credentials to set up the auxiliary credential rather
> than any other form of identity-proofing, but it does at least confer
> better assurance that it's the same individual on return trips.
>
> If it's the former, then the easiest hack approach is probably to modify
> the cancellation button into a continuation button or add a third
> button(again in /views).  You'll probably also have change the flow for
> duo-authn-flow.xml so that "proceed" means proceed rather than validation
> of the Duo response.  This involves delving into the system directory(not
> generally wise).  You may have to repeat that last step if you have to
> upgrade during your transition period.
>
> A cleaner hack would be the above, but duplicate the Duo part of the
> system flows, put it in the normal flows directory, give it a new name like
> authn/DuoRollout, and call that in your MFA script instead of authn/Duo.
>
> Note that this can cause your IdP to lie in the assertion and say that the
> user has been authenticated with Duo when they just opted past the device
> enrollment process.  Most service providers don't even check, though,
> putting the onus on the IdP anyway.
>
> Typically, MFA outreach campaigns are done as organizational educational
> efforts rather than something spliced into the login process.  You might
> consider something similar, and Duo has materials on hand that your
> organization can use.
>
> Hope this helps,
> Nate.
>
>
> On Sun, Sep 16, 2018 at 11:22 AM, Amanda Cairns <amanada.cairns at gmail.com>
> wrote:
>
>> Our institution has recently signed-on for Duo as MFA. It's a big change
>> for the users and initially we plan on running a recruiting campaign to
>> alert users to register their devices in advance to go-live.
>>
>> Duo will be triggered on go-live based on group memberships (successfully
>> tested and validated with 3.3.3).
>>
>> In advance of go-live, we wish to alert these same set of user to
>> register their devices.
>>
>> This will be a page they will see on entering their username/password
>> (similar to Duo MFA). The page will have to links --- 1. Go to device
>> registrations & 2.Continue.
>>
>> I was thinking of reverse engineering the Duo plugin and repeating the
>> logic, but that seemed like it could be an overkill for a simple alert
>> page.
>>
>> Could there be a more efficient way that I haven't thought of yet?
>>
>> Nanda
>>
>> --
>> For Consortium Member technical support, see
>> https://wiki.shibboleth.net/confluence/x/coFAAg
>> To unsubscribe from this list send an email to
>> users-unsubscribe at shibboleth.net
>>
>
> --
> For Consortium Member technical support, see
> https://wiki.shibboleth.net/confluence/x/coFAAg
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net



-- 
Karla Borecky
Systems Administrator
ITS
Smith College
Northampton, MA 01063
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20180917/c56f1c39/attachment.html>


More information about the users mailing list