Questions about configuring multiple Duo integrations on our IdP

[Les LaCroix]

>
> 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.


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).

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.

The complexity is still there; it's just spread out to other places, rather
than being solely in the IdP configuration.

-Les

------------------------------
Les LaCroix '79 | Strategic Technologist
Carleton College | 1 N. College St. | MS 3-ITS | Northfield, MN 55057
507.222.5455


On Thu, May 7, 2020 at 8:41 AM Michael A Grady <mgrady at unicon.net> wrote:

>
>
> On May 7, 2020, at 7:43 AM, David A. Kovacic <dak at case.edu> wrote:
>
> 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.
>
> In researching the issue, we've come across
> https://wiki.shibboleth.net/confluence/display/IDP[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.
>
> My questions:
>
>    1. 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.
>    2. 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?
>
> 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
>
> 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.
>
> 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.
>
> --
> Michael A. Grady
> IAM Architect, Unicon, Inc.
>
>
>
> --
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20200507/45d22115/attachment.htm>