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

On Mon, Sep 10, 2018 at 9:55 AM 'jhawkesworth' via CAS Community <
cas-user@apereo.org> wrote:

> 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
>
>
>
> On Saturday, September 8, 2018 at 4:37:08 AM UTC+1, baron wrote:
>>
>> 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/eb227550-4783-411e-a771-d63f8226cec8%40apereo.org
> <https://groups.google.com/a/apereo.org/d/msgid/cas-user/eb227550-4783-411e-a771-d63f8226cec8%40apereo.org?utm_medium=email&utm_source=footer>
> .
>

-- 
- 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/CAJ%3D0EZzHvF5jDK7VMaOCyxJ379w_qafOjcuff1H%3Dap7ZkqsyMA%40mail.gmail.com.

Reply via email to