<div dir="ltr">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.<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Hope this helps -</div><div>Karla B</div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Sep 17, 2018 at 1:39 AM Nate Klingenstein <<a href="mailto:ndk@sudonym.me">ndk@sudonym.me</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr">Nanda,<div><br></div><div>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?</div><div><br></div><div>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.</div><div><br></div><div><a href="https://guide.duo.com/add-device" target="_blank">https://guide.duo.com/add-device</a><br></div><div><br></div><div>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.</div><div><br></div><div>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<span style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"> into the system directory(not generally wise).</span>  You may have to repeat that last step if you have to upgrade during your transition period.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Hope this helps,</div><div>Nate.</div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Sep 16, 2018 at 11:22 AM, Amanda Cairns <span dir="ltr"><<a href="mailto:amanada.cairns@gmail.com" target="_blank">amanada.cairns@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>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. <br></div><div><br></div><div>Duo will be triggered on go-live based on group memberships (successfully tested and validated with 3.3.3).</div><div><br></div><div>In advance of go-live, we wish to alert these same set of user to register their devices.</div><div> </div><div>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.</div><div><br></div><div>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. </div><div><br></div><div>Could there be a more efficient way that I haven't thought of yet?</div><div><br></div><div>Nanda<br></div></div>
<br>-- <br>
For Consortium Member technical support, see <a href="https://wiki.shibboleth.net/confluence/x/coFAAg" rel="noreferrer" target="_blank">https://wiki.shibboleth.net/confluence/x/coFAAg</a><br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net" target="_blank">users-unsubscribe@shibboleth.net</a><br></blockquote></div><br></div>
-- <br>
For Consortium Member technical support, see <a href="https://wiki.shibboleth.net/confluence/x/coFAAg" rel="noreferrer" target="_blank">https://wiki.shibboleth.net/confluence/x/coFAAg</a><br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net" target="_blank">users-unsubscribe@shibboleth.net</a></blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div style="margin-left:40px">Karla Borecky<br>Systems Administrator<br>ITS<br>Smith College<br>Northampton, MA 01063<br></div><div style="margin-left:40px"><br></div><div style="margin-left:40px"><br></div></div></div></div></div></div></div></div>