CAS 5 RC4: /serviceValidate, /samlValidate fail after initial success

[Baron Fujimoto]

We're seeing the following errors with our RC4 regression tests. Initially,
after starting or reloading CAS, /serviceValidate and samlValidate succeed.

Shortly thereafter however, they fail subsequent runs of the same tests.
The failures appear to occur when the the app is accessed via SSO. An ST
is granted to the app, and it looks like it is successfully validated in
the logs, but the app gets back "Ticket not recognized" responses.

It looks like it may be trying to enforce a renew on the *Validate even
when it's not specified as a parameter?

Logs:

DEBUG [org.apereo.cas.CentralAuthenticationServiceImpl] - <Publishing org.apereo.cas.support.events.CasServiceTicketGrantedEvent@312bfa23[ticketGrantingTicket=TGT-**********************************************s5BTJTGdYr-cas75,serviceTicket=ST-46-uItdXfm5YblKsGwcCMfB-cas]>
DEBUG [org.apereo.cas.CentralAuthenticationServiceImpl] - <Publishing org.apereo.cas.support.events.CasServiceTicketValidatedEvent@2fca4214[assertion=org.apereo.cas.authentication.DefaultAuthentication@67d43765:https://www.example.com/app2,serviceTicket=ST-46-uItdXfm5YblKsGwcCMfB-cas]>
DEBUG [org.apereo.cas.validation.Cas20WithoutProxyingValidationSpecification] - <Number of chained authentications in the assertion 1>
WARN [org.apereo.cas.validation.Cas20WithoutProxyingValidationSpecification] - <Cas20WithoutProxyingValidationSpecification is to enforce the [renew] CAS protocol behavior, yet the assertion is not issued from a new login>
WARN [org.apereo.cas.web.ServiceValidateController] - <Service ticket [ST-46-uItdXfm5YblKsGwcCMfB-cas] does not satisfy validation specification.>

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

[Baron Fujimoto]

This is the specific sequences we tested:

- /login in to app1
- validate the CAS ticket we got for app1
- /login to app2, expect SSO to happen (it does)
- validate the CAS ticket we got for app2
- validation fails as described previously

also:

- /login(1) to app1, renew=true
- validate the CAS ticket we got for app1, renew=true
- /login(2) to app1 (again), renew=true (prompted for credentials again as expected)
- validate the CAS ticket we got for app1 (login2), renew=true
- validation fails as described previously

If we hit the /logout endpoint between login1 and login2 in this second
test sequence, then the validations succeed as expected.

I'm not sure exactly what all of our application testers are doing in
their applications, but based on their feedback and what we see in the
logs, it looks like similar things are happening. We see STs granted from
the TGT, then the ST validation succeed, but then fail as described below.

FWIW, we also see this logged:

DEBUG [org.apereo.cas.web.view.CasReloadableMessageBundle] - <The code [INVALID_TICKET] cannot be found in the language bundle for the locale [en_US]>

Aloha,
-baron

On Thu, Oct 13, 2016 at 01:28:55AM +0330, Misagh Moayyed wrote:
>Your diagnosis certainly is correct, and this points to a possible bug. The renew flag that is passed along once seems to stay around for subsequent requests on the validator, and it should not. Trivial fix really.
>
>Not that it matters, I don’t think, but let me ask: when you authn into app A once and login successfully, is it the same app A that fails to receive validated tickets next such that you log out of app A and attempt to try again via SSO? Or is it an entirely different app trying to take advantage of SSO? 
>
>-- 
>Misagh

>--
>CAS gitter chatroom: https://gitter.im/apereo/cas
>CAS mailing list guidelines: https://apereo.github.io/cas/Mailing-Lists.html
>CAS documentation website: https://apereo.github.io/cas
>CAS project website: https://github.com/apereo/cas
>---
>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 post to this group, send email to cas-...@apereo.org.
>Visit this group at https://groups.google.com/a/apereo.org/group/cas-user/.
>To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/20161012205856.GB23083%40praenomen.mgt.hawaii.edu.
>For more options, visit https://groups.google.com/a/apereo.org/d/optout.

[Misagh Moayyed]

Your diagnosis certainly is correct, and this points to a possible bug. The renew flag that is passed along once seems to stay around for subsequent requests on the validator, and it should not. Trivial fix really.

Not that it matters, I don’t think, but let me ask: when you authn into app A once and login successfully, is it the same app A that fails to receive validated tickets next such that you log out of app A and attempt to try again via SSO? Or is it an entirely different app trying to take advantage of SSO? 

-- 
Misagh

From: Baron Fujimoto <ba...@hawaii.edu>
Reply: Baron Fujimoto <ba...@hawaii.edu>
Date: October 13, 2016 at 12:29:15 AM
To: CAS Users <cas-...@apereo.org>
Subject:  [cas-user] CAS 5 RC4: /serviceValidate, /samlValidate fail after initial success

-- br/>Baron FFujimoto <ba...@hawaii.edu> :: UH Information Technology Services

minutas cantorum, minutas balorum, minutas carboratum desendus pantorum

-- br/>CAS gitter chatroom: https://gitter.im/apereo/cas <

CAS mailing list guidelines: https://apereo.github.io/cas/Mailing-Lists.html
CAS documentation website: https://apereo.github.io/cas
CAS project website: https://github.com/apereo/cas

--- br/>You received this message because you are subscribed to the Google Groups "CAS Community" group.