CAS 6.3.5 renew=true bug for /validate and /serviceValidate

[Baron Fujimoto]

(originally from a different thread, but seems topically different enough to warrant its own)

There seems to be a bug handling renew=true for /validate and /serviceValidate for CAS 6.3.5. It also seems to be present in the current 6.4-snapshot.

If we first establish an SSO session by logging in to app1, then we login to app2 (without setting renew=true) and attempt to either /validate or /serviceValidate app2 with renew=true, we expect this to fail, but instead it succeeds. It does fail as expected with /samlValidate, so this behavior is not consistent among the validation methods. This is a change from 6.3.4.

--

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

[King, Robert]

Would it be possible to see the service entry for app2?

--
- 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/CAAjLUL2MiCgjHgm9AT2tC4_S0htRrngTSkYBU_6xaW0drRQinA%40mail.gmail.com.

[Baron Fujimoto]

Do you mean the service registration? We use a JSON file-based service registry, and this is what we're using for our regression tests:

{
  "name" : "IAM CAS Regression Test",
  "description" : "CAS regression test",
  "serviceId" : "^https://(www\\.)*example\\.com/regression(/.*)*",
  "id" : 10000003,
  "evaluationOrder" : 10,
  "multifactorPolicy" : {
    "@class" : "org.apereo.cas.services.DefaultRegisteredServiceMultifactorPolicy",
    "multifactorAuthenticationProviders" : [ "java.util.LinkedHashSet", [ "mfa-duo" ] ],
    "failureMode" : "OPEN"
  }
  "@class" : "org.apereo.cas.services.RegexRegisteredService",
}

Our regression tests are basically doing the following:

Establish SSO:

https://cas.example.edu/cas/login?service=https://www.example.com/regression/app1&renew=true

Test renew=true against established SSO:

https://cas.example.edu/cas/login?service=https://www.example.com/regression/app2

https://cas.example.edu/cas/validate?service=https://www.example.com/regression/app2&ticket=ST-...-cas&renew=true

We expect this to fail due to the inclusion of renew=true in the validation. However, instead the ST is successfully validated. We see this for both /validate and /serviceValidate. /samlValidate fails as expected. Prior to 6.3.5, all would fail as expected.

In practice, it would probably be unusual to not specify renew=true for both login and validation of app2, but we do so here to explicitly test renew=true on the validation. And minimally, we think the results should at least be consistent among the validation methods.

To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/b889bfa6b7454193a048889d34cbc41f%40mun.ca.

[King, Robert]

Out of curiosity, would it be possible to move to two service entries for app1 vs app2?

 

I am wondering if you added the following for app2:

 

{
  "name" : "IAM CAS Regression Test app2",
  "description" : "CAS regression test app2",
  "serviceId" : "^https://(www\\.)*example\\.com/regression/app2(/.*)*",
  "id" : 10000004,

  "evaluationOrder" : 10,
  "multifactorPolicy" : {
    "@class" : "org.apereo.cas.services.DefaultRegisteredServiceMultifactorPolicy",
    "multifactorAuthenticationProviders" : [ "java.util.LinkedHashSet", [ "mfa-duo" ] ],
    "failureMode" : "OPEN"
  }
  "@class" : "org.apereo.cas.services.RegexRegisteredService",

  "accessStrategy" : {

    "@class" : "org.apereo.cas.services.DefaultRegisteredServiceAccessStrategy",

    "enabled" : true,

    "ssoEnabled" : false

  }
}

 

Functionally the “ssoEnabled” option is supposed to be equivalent to “renew=true”.  I am wondering if it is set server side, will it exhibit the same behavior.

 

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

[Baron Fujimoto]

With that service registry for app2, our test balks at trying to login to app2 via SSO, so it appears to prevent that as if renew=true were set on /login. I didn't test specifically, but assuming non-SSO login were used here, then at that point any of the validation methods succeeding would be expected.

To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/c834b39fb6144eaeadce37005be084f4%40mun.ca.