[cas-user] Re: CAS 5.3.3 - SAML 1.1 - Custom Saml 1.1 client not able to retrieve the assertion.

[Curtis Ruck]

I believe all of the above is due to a missing TARGET query parameter.

I really wish we had better parameter validation and logging for things 
like this.

-- 
- 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/58946e58-b969-4257-8c95-2a1ab19ce406%40apereo.org.

[cas-user] Re: CAS 5.3.3 - SAML 1.1 - Custom Saml 1.1 client not able to retrieve the assertion.

[Curtis Ruck]

Following the logic back with TRACE logging on, it appears inside 
DefaultArgumentExtractor.java 

 its 
generating 2 of 3 different service objects.

SamlService with id=null (what i'm seeing in the logs that later NPE's in 
URLDecoder.decode).
SimpleWebApplicationServiceImpl with id=https://example.com/foo/bar not 
seeing these anywhere
and its logging "No service could be extracted based on the given request." 
this causes it to return null, which makes service=null in 
AbstractServiceValidateController.handleRequestInternal, which i'm not 
seeing i don't believe.

These all 3 appear to be getting logged, as if there are multiple 
ServiceFactories registered.


-- 
- 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/b4cca3ca-ad4e-4a12-ba91-75e3e90a26b4%40apereo.org.

[cas-user] Re: CAS 5.3.3 - SAML 1.1 - Custom Saml 1.1 client not able to retrieve the assertion.

[Curtis Ruck]

This has me completely confused.  I'm trying to nail down a stack trace, 
for some reason its not logging stack traces after the log file rolls over; 
and this particular client is dumb, and just keeps trying infinitely 
without any backoff algorithm when failures repeatedly occur.  It appears 
that whatever AbstractWebApplicationService is (i assume its supposed to be 
SamlService, but SamlService doesn't have a @ToString.

2018-09-10 16:15:42,078 DEBUG 
[org.apereo.cas.AbstractCentralAuthenticationService] - 
2018-09-10 16:15:42,078 DEBUG 
[org.apereo.cas.ticket.registry.AbstractTicketRegistry] - 
2018-09-10 16:15:42,079 DEBUG 
[org.apereo.cas.ticket.registry.AbstractTicketRegistry] - 
2018-09-10 16:15:42,079 DEBUG 
[org.apereo.cas.ticket.registry.AbstractTicketRegistry] - 
2018-09-10 16:15:42,080 ERROR 
[org.apereo.cas.authentication.principal.Service] - 
java.lang.NullPointerException: null
2018-09-10 16:15:42,080 ERROR 
[org.apereo.cas.DefaultCentralAuthenticationService] - https://example.com/foo/bar] does not match supplied service 
[AbstractWebApplicationService(id=null, originalUrl=null, 
artifactId=ST-4920--b-TI-JNe91v7ZP1P49EEXhndtwv325-core, principal=null, 
source=TARGET, loggedOutAlready=false, format=XML, attributes={})]>
2018-09-10 16:15:42,080 DEBUG 
[org.apereo.cas.ticket.support.MultiTimeUseOrTimeoutExpirationPolicy] - 

2018-09-10 16:15:42,081 DEBUG 
[org.apereo.cas.ticket.registry.AbstractTicketRegistry] - 
2018-09-10 16:15:42,081 DEBUG 
[org.apereo.cas.ticket.registry.AbstractTicketRegistry] - 
2018-09-10 16:15:42,082 DEBUG 
[org.apereo.cas.ticket.registry.AbstractTicketRegistry] - 
2018-09-10 16:15:42,082 DEBUG 
[org.apereo.cas.ticket.registry.AbstractTicketRegistry] - 
2018-09-10 16:15:42,082 DEBUG 
[org.apereo.cas.ticket.registry.AbstractTicketRegistry] - 
2018-09-10 16:15:42,083 INFO 
[org.apereo.inspektr.audit.support.Slf4jLoggingAuditTrailManager] - 
2018-09-10 16:15:42,097 DEBUG 
[org.opensaml.messaging.encoder.servlet.BaseHttpServletResponseXMLMessageEncoder]
 
- 
2018-09-10 16:15:42,097 DEBUG 
[org.opensaml.messaging.encoder.servlet.BaseHttpServletResponseXMLMessageEncoder]
 
- 
2018-09-10 16:15:42,097 DEBUG [PROTOCOL_MESSAGE] - <

http://schemas.xmlsoap.org/soap/envelope/;>




Ticket 
'ST-4920--b-TI-JNe91v7ZP1P49EEXhndtwv325-core' does not match supplied 
service. The original service was 'https://example.com/foo/bar' and the 
supplied service was 'null'.




>

-- 
- 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/b7559462-3a51-43c8-bbc9-9eff749b0a9e%40apereo.org.

[cas-user] CAS 5.3.3 - SAML 1.1 - Custom Saml 1.1 client not able to retrieve the assertion.

[Curtis Ruck]

So lets see if I can keep this simple.

I have a mostly working CAS 5.3.3 Server with SAML 1.1 working to the 
java-cas-client.  We have a vendor developed CAS Client for the CAS SAML 
1.1 protocol, that worked with CAS 3.3, 3.5, and 3.6.  Now on CAS 5.3.3, 
it's getting a samllp:RequestDenied samllp:Response.

Based on reviewing the code, it appears it's failing at 
DefaultCentralAuthenticationService.java:301 
.
  
Do i need to create a SamlRegisteredService service definition for SAML 1.1 
instead of using RegexRegisteredService?  Based on the error, I expected to 
see service as part of the validation request to /samlValidate, but it's 
not part of the SAML 1.1 specification that I can find.

The received response:

http://schemas.xmlsoap.org/soap/envelope/;>




Ticket 'ST-104183-x-cas' 
does not match supplied service. The original service was 
'https://example.com/foo/bar' and the supplied service was 
'null'.





-- 
- 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/73251842-4c67-4fcc-9286-23d0a11aecff%40apereo.org.

Re: [cas-user] disabling MFA, MFA failure modes

[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

On Mon, 10 Sep 2018 at 16:30, Travis Schmidt 
wrote:

> PR (https://github.com/apereo/cas/pull/3509) has been submitted to
> correct this.
>
> On Mon, Sep 10, 2018 at 8:03 AM Travis Schmidt 
> wrote:
>
>> 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.
>>
>>
>> On Mon, Sep 10, 2018 at 7:15 AM Tepe, Dirk  wrote:
>>
>>> 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 

Re: [cas-user] disabling MFA, MFA failure modes

[Travis Schmidt]

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

On Mon, Sep 10, 2018 at 8:03 AM Travis Schmidt 
wrote:

> 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.
>
>
> On Mon, Sep 10, 2018 at 7:15 AM Tepe, Dirk  wrote:
>
>> 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

Re: [cas-user] disabling MFA, MFA failure modes

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


On Mon, Sep 10, 2018 at 7:15 AM Tepe, Dirk  wrote:

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

[cas-user] Surrogate authentication failing

[Tepe, Dirk]

We're interested in using surrogate authentication for some support staff.
I had done a quick proof-of-concept under CAS 5.2.x a while ago, enough to
demonstrate it worked. We are now working with 5.3.3 and starting to build
the actual functionality, but are running into a problem. I'm using a
static entry in the cas.properties file and have removed several
dependencies added since the POC.

Some relevant snippets from the log are included below. I have run this
with DEBUG and did not see anything immediately more helpful.

You can see that the surrogate authorization is actually successful in the
first chunk and the service ticket is successfully validated. The problem
appears to be in the building of the validation response. It looks like
surrogate authentication changes at least one of the credential attributes
from a string to hash and causes this problem.

This seems somewhat similar to another thread related to the MFA bypass
functionality giving a INVALID_AUTHENTICATION_CONTEXT error, also when
building the response after successful service ticket validation.

Has anyone dealt with this type of issue?

Thanks,

-dirk

2018-09-10 14:09:38,399 INFO
[org.apereo.inspektr.audit.support.Slf4jLoggingAuditTrailManager] -
<{"who":"(Primary User: [[v*]], Surrogate User:
[[t*]])","what":"[result=Service Access Granted,service=
https://web.test/duo-validator/duo,requiredAttributes={}]","action":"SERVICE_ACCESS_ENFORCEMENT_TRIGGERED","application":"CAS","when":"Mon
Sep 10 14:09:38 UTC
2018","clientIpAddress":"192.168.34.1","serverIpAddress":"192.168.34.120"}>
2018-09-10 14:09:38,436 INFO
[org.apereo.cas.DefaultCentralAuthenticationService] - https://web.test/duo-validator/duo] and principal [t*]>
2018-09-10 14:09:38,442 INFO
[org.apereo.inspektr.audit.support.Slf4jLoggingAuditTrailManager] -
<{"who":"(Primary User: [[v*]], Surrogate User:
[[t*]])","what":"ST-1-UHQvQ88buWL-FRkdZBgbQxX0N78cas-1 for
https://web.test/duo-validator/duo","action":"SERVICE_TICKET_CREATED","application":"CAS","when":"Mon
Sep 10 14:09:38 UTC
2018","clientIpAddress":"192.168.34.1","serverIpAddress":"192.168.34.120"}>
...
2018-09-10 14:09:41,886 INFO
[org.apereo.inspektr.audit.support.Slf4jLoggingAuditTrailManager] -
<{"who":"(Primary User: [[v*]], Surrogate User:
[[t]])","what":"ST-1-UHQvQ88buWL-FRkdZBgbQxX0N78cas-1","action":"SERVICE_TICKET_VALIDATED","application":"CAS","when":"Mon
Sep 10 14:09:41 UTC
2018","clientIpAddress":"192.168.34.10","serverIpAddress":"192.168.34.120"}>
2018-09-10 14:09:41,944 ERROR
[org.apache.catalina.core.ContainerBase.[Tomcat].[localhost].[/cas].[dispatcherServlet]]
- 
java.lang.ClassCastException: java.util.LinkedHashSet cannot be cast to
java.lang.String
  at
org.apereo.cas.services.web.view.AbstractCasView.getAuthenticationAttribute(AbstractCasView.java:160)
~[cas-server-core-web-api-5.3.3.jar!/:5.3.3]
  at
org.apereo.cas.services.web.view.AbstractCasView.decideIfCredentialPasswordShouldBeReleasedAsAttribute(AbstractCasView.java:309)
~[cas-server-core-web-api-5.3.3.jar!/:5.3.3]
  at
org.apereo.cas.web.view.Cas30ResponseView.prepareMergedOutputModel(Cas30ResponseView.java:73)
~[cas-server-support-validation-5.3.3.jar!/:5.3.3]

-- 
- 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%3D0EZyQA1qjs6FhtamHRb-qCQv_21_CGtVBuMw2%2BpCNba2jEg%40mail.gmail.com.

Re: [cas-user] disabling MFA, MFA failure modes

[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

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 

Re: [cas-user] disabling MFA, MFA failure modes

['jhawkesworth' via CAS Community]

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