A closer review of the cas properties documentation suggests that setting 
cas.authn.mfa.globalFailureMode=NONE wouldn't have the desired effect after 
all. It doesn't disable MFA, just assumes the MFA provider is avialable. So I 
should back up and reformulate my question:

Is there a way to configure CAS to disable MFA globally, ideally via the 
cas.properties file in a way that will override anything that may be set in an 
individual service registration? I suppose you could take the dependency out of 
the overlay and rebuild CAS, but that seems like overkill (and would that 
approach cause it to choke on MFA references already present in the 
cas.properties or services registrations?).

On Tue, Sep 04, 2018 at 05:59:58PM -1000, Baron Fujimoto wrote:
>Yes, we're essentially relying on the Duo integration to determine whether the 
>user needs MFA and we're hitting Duo with every AuthN. Our CAS isn't currently 
>set configured up to check a group for Duo-enabled membership. Thus our desire 
>to simply disable MFA altogether (by executive decision) in dire circumstances.
>
>On Tue, Sep 04, 2018 at 03:39:14PM -0500, Richard Frovarp wrote:
>>Yeah, but how do they opt in? You're basically relying on the Duo integration
>>to come back and say that the user needs to MFA? That means that you're
>>hitting Duo every auth, even if the user hasn't opted in. Which means these
>>sorts of events are really nasty if that is the case. I also can't remember
>>which one it was, but either CAS or Shibboleth were asserting that MFA had
>>happened if Duo came back and said that the user didn't have to MFA. So the
>>attribute release back to SPs started to get ugly.
>>
>>Like I said with ours, we check an AD group first. So we don't even query the
>>Duo integration until that group check passes. The integration is configured
>>to always require MFA is it is asked.
>>
>>I certainly get your point about not wanting to change all of them. I'm in
>>part saying that the last two issues appeared to have failed in two different
>>ways, neither of which is one that the library anticipated. If I ever get
>>some time, I'd like to look at how the code is working, and improve it. But
>>I'm 90% sure that out of the box there is no way to configure it so that it
>>would have handle either of those two incidents, as it wasn't going to detect
>>them. Your best bet would have been to block traffic at the edge so that Duo
>>wasn't even reachable. Then the ping would have failed, and CAS would have
>>had a chance to fall into its error handling routines for MFA.
>>
>>On 09/04/2018 03:21 PM, Baron Fujimoto wrote:
>>> We're enabling Duo via the multifactor section in each service registration 
>>> as below. However, this is in our default service registration template and 
>>> is present in our hundreds of registered services (our users currently 
>>> opt-in to MFA/Duo). It would be, uhh, non-optimal for us to have to go in 
>>> and tweak each such registration in events like this. We had been hoping 
>>> that setting cas.authn.mfa.globalFailureMode in the global cas.properties 
>>> config would supercede the properties in the individual service 
>>> registrations which would allow us to just have to make the manual 
>>> adjustment there if necessary.
>>> 
>>> On Tue, Sep 04, 2018 at 10:07:08AM -0500, Richard Frovarp wrote:
>>> > I think that CAS does an API ping to check availability. At least that's 
>>> > what
>>> > I saw in the code when I took a peak a couple of months ago. We're also on
>>> > DUO1, and that was succeeding during the DUO1 outages. In fact, it
>>> > immediately succeeded. I even called out the fact that this was happening 
>>> > to
>>> > Duo, and they directed me to the contingency plan document. The issue 
>>> > during
>>> > those outages was that all of the requests were queuing up, and so the
>>> > connection was alive, but nothing useful was happening. Not sure what 
>>> > sort of
>>> > timeouts are involved, but they are quite long.
>>> > 
>>> > During the first outage, it was failing for us at the Duo widget display
>>> > screen. During the second outage, it was failing after credentials, but
>>> > before the widget screen. I haven't looked, but I'm guessing that CAS is
>>> > doing some sort of pre-auth or other API check after login, and before 
>>> > widget
>>> > display to decide if that should be invoked. Given that the page rendered,
>>> > but the widget didn't, it looks like the failure from the first outage (at
>>> > least for us) was a timeout on the browser side, which isn't something 
>>> > that
>>> > CAS will be able to detect. Being able to timeout on the CAS side quickly
>>> > would have helped with the second time. I don't think we're configured to
>>> > fail open, but I also don't think that would have helped.
>>> > 
>>> > How are you deciding to do Duo? We're doing a AD group check. So our
>>> > contingency was/is to change the config file to any group that doesn't 
>>> > match
>>> > an existing group. Then the local check fails and it doesn't even try Duo.
>>> > That requires human intervention. But a quick touch of the config file 
>>> > after
>>> > change causes it to immediately reload and take the changes into effect. 
>>> > We
>>> > do something similar with Shibboleth IdP for InCommon.
>>> > 
>>> > On 08/31/2018 11:01 PM, Baron Fujimoto wrote:
>>> > > We're considering contingencies to MFA failures in light of recent 
>>> > > service problems with Duo.
>>> > > 
>>> > > We're currently still using CAS 5.0.x. I'm assuming the property of 
>>> > > interest for us here is cas.authn.mfa.globalFailureMode. The 
>>> > > documentation doesn't really make this clear, but specifically what MFA 
>>> > > is/isn't "communicated to the client if provider" is unavailable for 
>>> > > PHANTOM/OPEN modes? How does these differ from NONE?
>>> > > 
>>> > > <https://apereo.github.io/cas/5.0.x/installation/Configuring-Multifactor-Authentication.html#fail-open-vs-fail-closed>
>>> > > 
>>> > > We also MFA enabled for each registered service with the following:
>>> > > 
>>> > >     "multifactorPolicy" : {
>>> > >       "@class" : 
>>> > > "org.apereo.cas.services.DefaultRegisteredServiceMultifactorPolicy",
>>> > >       "multifactorAuthenticationProviders" : [ 
>>> > > "java.util.LinkedHashSet", [ "mfa-duo" ] ],
>>> > >       "failureMode" : "OPEN"
>>> > >     }
>>> > > 
>>> > > I appears however, that setting cas.authn.mfa.globalFailureMode=NONE in 
>>> > > cas.properties is not sufficient to disable/bypass MFA. I am still 
>>> > > prompted for it. Should globalFailureMode in cas.properties take 
>>> > > precedence over failureMode in the service registration, or vice versa? 
>>> > > Or is this not the right way to achieve this goal?
>>> > > 
>>> > > We are thinking that OPEN may not be desired in the rare cases where 
>>> > > Duo may be technically available (how does CAS detemine Duo's 
>>> > > availability?), but the service has degraded unacceptably.
>>> > > 

-- 
Baron Fujimoto <ba...@hawaii.edu> :: UH Information Technology Services
minutas cantorum, minutas balorum, minutas carboratum desendus pantorum

-- 
- Website: https://apereo.github.io/cas
- Gitter Chatroom: https://gitter.im/apereo/cas
- List Guidelines: https://goo.gl/1VRrw7
- Contributions: https://goo.gl/mh7qDG
--- 
You received this message because you are subscribed to the Google Groups "CAS 
Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cas-user+unsubscr...@apereo.org.
To view this discussion on the web visit 
https://groups.google.com/a/apereo.org/d/msgid/cas-user/20180908033702.tjgu2ulwjpbijgs3%40combobulate.mgt.hawaii.edu.

Reply via email to