disabling MFA, MFA failure modes

[Baron Fujimoto]

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

[Richard Frovarp]

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.

[Baron Fujimoto]

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.

>--
>- 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+u...@apereo.org.
>To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/a7ca2d94-cb76-46af-164e-c3dd4784e044%40ndsu.edu.

[Richard Frovarp]

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.

[Baron Fujimoto]

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.

>To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/5d60245a-1727-f4bf-e969-fb1930d8a734%40ndsu.edu.

[Andrew Marker]

I like the idea of a configurable timeout for mfa globally or mfa provider-service level.  The other ideas related to being able to disable it quickly or set discreet failure modes for populations and at the service level (which i think we can do already?) are really nice features/value adds.

Having the request marked as a failure if it takes too long will allow the existing process/contingency to kick in. This, in my opinion is critical.

 We never hit fail-open in the last DUO event we had because the duo service never hung up.  The contingency that is in place never materialized:  CAS 5.2.6 and CAS 5.2.7 are the versions in use when our two DUO failures occurred btw.

[Travis Schmidt]

This PR (https://github.com/apereo/cas/pull/3493) was merged into 5.3.x branch, and I think has been ported into some 5.2.x versions to try and address some of these issues. 

--

- 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+u...@apereo.org.

To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/9f126146-db42-487e-9120-1e1de96eebdd%40apereo.org.

[Andrew Marker]

Thanks Travis. 

To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/CAC_RtEaO3jYH0_%2B2SUnvfbyMbKd45Paspi4ZK13k%3DwMamSu%2BXw%40mail.gmail.com.

[Baron Fujimoto]

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

[jhawkesworth]

Thanks for this thread.

I think perhaps having a groovy script which determines whether or not to bypass DUO might be the way forward?

In theory you can just change the groovy script (on each CAS node) if DUO is degraded and subsequent requests would then take notice of new bypass policy.

That said, I'm not able to get duo bypass fully working using with a groovy script.  The /login works, correctly identifying if duo is needed depending on our selection criteria, but /servicevalidate still fails with 

INVALID_AUTHENTICATION_CONTEXT

Just to be clear I am running against latest snapshot 5.3.4-SNAPSHOT, so should have  https://github.com/apereo/cas/pull/3493 included but I'm still getting the INVALID_AUTHENTICATION_CONTEXT failure for all users (not just those who should/shouldn't be required to 2FA) as soon as I configure duo for a service.

Can anyone share how they have got bypass working with DUO?

This comment https://github.com/apereo/cas/pull/3493#discussion_r213138134 

• "There is no bypassProvider created currently unless one is defined in cas.properties" seems to hint that something needs explicit configuration in cas.properties.

I am just setting the following (along with the duo keys):

cas.authn.mfa.duo[0].id=mfa-duo

cas.authn.mfa.duo[0].bypass.type=GROOVY

cas.authn.mfa.duo[0].bypass.groovy.location=file:/etc/cas/config/mfa-bypass.groovy

Am I missing something?

Debugging into AbstractServiceValidateController it appears there's no bypassEvaluator for duo (see below), so this is presumably why cas things it needs to get duo to do something in order to validate the ST.

duoMultifactorAuthenticationProvider=AbstractMultifactorAuthenticationProvider(bypassEvaluator=null, globalFailureMode=null, id=mfa-duo, order=0)

Somewhat related, I'm wondering if I should instead by using 'trigger' instead of 'bypass' - are they simply semantic default-not-to-try / default-is-to-try or is there something more subtle going on?    In my case some users won't even be registered with DUO 

Any help greatly appreciated.  

All the best,

Jon

[Tepe, Dirk]

I'm literally dealing with the same error and decision of trigger vs bypass right now. We were triggering all users for Duo, then deciding in the groovy script which to bypass. This works fine when simply judging by the prompt for Duo or not, but we also got the INVALID_AUTHENTICATION_CONTEXT when the service validates the ticket. The logs indicate the validation was successful which seems to lead to a problem building the validation response.

I am in the process of moving our logic to the trigger groovy script, which appears to provide the desired behavior. I'm not clear on the intended use case of "trigger" vs "bypass" or what the ramification of this move will be, however.

-dirk

--

- 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+u...@apereo.org.

To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/eb227550-4783-411e-a771-d63f8226cec8%40apereo.org.

[Travis Schmidt]

This is an issue where if you indicate bypass from a script, the the authentication is not correctly marked as being bypassed and the context validator then rejects.  Also be aware that currently if you choose GROOVY or REST for bypass providers, this overrides all rules in DEFAULT.  Meaning if you mark a service as "Bypass Enabled" in your service registry, the bypass will not be honored, unless you write your script to check that flag.   

 

To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/CAJ%3D0EZzHvF5jDK7VMaOCyxJ379w_qafOjcuff1H%3Dap7ZkqsyMA%40mail.gmail.com.

[Travis Schmidt]

PR (https://github.com/apereo/cas/pull/3509) has been submitted to correct this.  

[Jon Hawkesworth]

Great, thank you so much for tackling this!

As soon as I have figured out the best way for me to test your PR I will comment on it.

Jon

To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/CAC_RtEbspZGxdFNDigE6ievh_%3D6y1ug3Q-MWffUWsrz63KKEvA%40mail.gmail.com.

[jhawkesworth]

Just to follow up (in a less huge font) https://github.com/apereo/cas/pull/3509 fixed the  INVALID_AUTHENTICATION_CONTEXT issue for me.

All the best,

Jon