<div dir="ltr"><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><span style="color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif">Another way to handle your use case is to stick with a single Duo integration, but have logic in mfa-authn-config based on user affiliation attribute(s), and simply don't require Duo (don't send the user to Duo) if the user is alumni. We've seen that also.</span></blockquote><div class="gmail_default" style="font-family:trebuchet ms,sans-serif;font-size:small;color:#073763"><span style="color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif"><br></span></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif;font-size:small;color:#073763"><span style="color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif">That is essentially what we do. We have alumni and parent logins, a single Duo integration for SSO, and Duo licenses to cover regular faculty, staff, and students. Most faculty/staff/students are required to enroll in Duo; some are eligible to opt-in, and some not. IAM sorts out who is required plus who has opted in and signals the Duo flow to trigger (or not).</span></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif;font-size:small;color:#073763"><span style="color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif"><br></span></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif;font-size:small;color:#073763"><span style="color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif">The added benefit of not tying it directly to basic affiliation is that we can postpone the Duo enforcement for new faculty and students until we know they are on campus, rather than enforcing it as soon as they get their accounts in the summer. The help desk likes that a lot.</span></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif;font-size:small;color:#073763"><span style="color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif"><br></span></div><div class="gmail_default" style="font-size:small">The complexity is still there; it's just spread out to other places, rather than being solely in the IdP configuration.</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif;font-size:small;color:#073763"><span style="color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif"><br></span></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif;font-size:small;color:#073763"><span style="color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif">-Les</span></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><br><hr style="color:rgb(0,0,0);font-family:"times new roman","new york",times,serif;font-size:16px"><div style="color:rgb(0,0,0);font-family:"times new roman","new york",times,serif;font-size:16px;text-align:right"><span size="2" style="color:rgb(153,102,51);font-size:small">Les LaCroix '79 </span><span style="color:rgb(153,102,51)">|</span><span size="2" style="color:rgb(153,102,51);font-size:small"> </span><span size="2" style="color:rgb(153,102,51);font-size:small">Strategic Technologist<br></span><span size="2" style="color:rgb(153,102,51);font-size:small">Carleton College </span><span style="color:rgb(153,102,51)">|</span><span size="2" style="color:rgb(153,102,51);font-size:small"> 1 N. College St. </span><span style="color:rgb(153,102,51)">|</span><span size="2" style="color:rgb(153,102,51);font-size:small"> MS 3-ITS </span><span style="color:rgb(153,102,51)">|</span><span size="2" style="color:rgb(153,102,51);font-size:small"> Northfield, MN 55057<br></span><span size="2" style="color:rgb(153,102,51);font-size:small">507.222.5455</span></div></div></div></div></div></div></div></div></div></div></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 7, 2020 at 8:41 AM Michael A Grady <<a href="mailto:mgrady@unicon.net">mgrady@unicon.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><br><div><br><blockquote type="cite"><div>On May 7, 2020, at 7:43 AM, David A. Kovacic <<a href="mailto:dak@case.edu" target="_blank">dak@case.edu</a>> wrote:</div><br><div>
<div>
At CWRU our Information Security office is trying to deploy Duo
integration as widely as possible, and is hoping to switch the Duo
setting to require enrollment rather than giving a free pass to
those users not enrolled in Duo as it is currently configured.
Given that our alums retain access to G Suite services indefinitely
after graduation, we are forced to either purchase many more Duo
licenses, or to deploy multiple Duo integrations through our IdP. <br>
<br>
In researching the issue, we've come across
<a href="https://wiki.shibboleth.net/confluence/display/IDP" target="_blank">https://wiki.shibboleth.net/confluence/display/IDP</a>[3-4]/DuoAuthnConfiguration#DuoAuthnConfiguration-MultipleDuoIntegrations
which provides a script example that seems to be able to pretty much
be dropped into place with only the customization of the
duo.properties file and the URLs in the table that map to the
"special Duo". The example seems to do exactly what e need it to
do.<br>
<br>
My questions:<br>
<ol>
<li>Is this implementation really as straightforward as it appears
with just the customization of the URLs in the map and the
properties file, then a rebuild of the .war file, or is there
actually more involved in setting this up? None of our team is
that much of a Java programmer and we'd like to avoid writing
custom Java code if it can be avoided.</li>
<li>Has anyone implemented multiple Duo integrations using
something similar to the script example provided? If so did you
face any challenges, and what were they?</li>
</ol><p>We are currently running IdP 3, but are in the process of
upgrading to IdP 4 but the integration seems to be exactly the
same across both versions</p></div></div></blockquote></div>It does "just work". Don't need it often, but we know an organization using that exact approach to map to 3 different Duo integrations. And there is no need to rebuild the WAR file, you aren't touching anything that has to do with WAR file; you just need to restart the IdP.<div><br></div><div>Another way to handle your use case is to stick with a single Duo integration, but have logic in mfa-authn-config based on user affiliation attribute(s), and simply don't require Duo (don't send the user to Duo) if the user is alumni. We've seen that also.</div><div><br><div>
<div style="color:rgb(0,0,0);font-family:Helvetica;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">--<br>Michael A. Grady<br>IAM Architect, Unicon, Inc.</div><div style="color:rgb(0,0,0);font-family:Helvetica;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br></div><br>
</div>
<br></div></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><br>
</blockquote></div>