[Ext] Re: Forcing Duo by Service Provider

[Bryan Wooten]

³that "have enrolled" bit is where you're going to magnify the pain here.
Especially when Duo just enrolls you in real time anyway.²

No. Via the Duo Admin Console we have set ³deny un-enrolled users².

So yes there is the classic ³chicken and egg² problem. We use the self
service app written by U Chicago for enrollment. We do not use the built
in Duo enrollment feature.

Either way there is a window when a bad actor could hijack a user¹s
account. I have had  this conversation several times at I2. Like SLO there
is no perfect solution. At best we can mitigate risk. At best.

Since our IDP defers to CAS for authn it is simple, if your employment
status is ³current² (per LDAP) you will use MFA.

Once the user suffers this hassle they have a Duo account they will need
to use for access to things like PCI, VPN, RDP, ssh to backend servers.

Whether I am in the office or at home it takes me 3-4 Duo pushes to get
into the systems I need to resolve a tier 3 help ticket.

The ³chicken and egg² problem could mostly be resolved by an entirely
manual process, but that would not scale.

Again, I love the conversation and debate. This is healthy from both a
policy and technical point of view.

-B


On 3/31/17, 4:19 PM, "Cantor, Scott" <cantor.2 at osu.edu> wrote:

>On 3/31/17, 6:14 PM, "users on behalf of Andrew Morgan"
><users-bounces at shibboleth.net on behalf of morgan at orst.edu> wrote:
>
>> Agreed!  A simple solution is to use MFA all the time for people that
>>have 
>> enrolled in MFA (and require certain populations to enroll).
>
>That "have enrolled" bit is where you're going to magnify the pain here.
>Especially when Duo just enrolls you in real time anyway.
>
>> I'm investigating all of our possibilities to inform our policy-making
>> process.  We want to know what is possible, and how difficult it is,
>>for 
>> all of the scenarios we have dreamed up.  :)
>
>User-specific rules are going to take the IdP complexity level up an
>order of magnitude, so if you're really exploring the options, I would
>advise against that in the strongest terms.
>
>I can also personally vouch for that. We have only service-specific
>policy at this point at OSU-East and the IdP work has been minimal. The
>IdP is simply already set up to do service-based rules, whereas
>user-based is just not ever going to be clean because of the fundamental
>problem: you don't know who the user is until you know who the user is.
>
>-- Scott
>
>
>
>-- 
>To unsubscribe from this list send an email to
>users-unsubscribe at shibboleth.net