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 > >From: Baron Fujimoto <[email protected]> >Reply: Baron Fujimoto <[email protected]> >Date: October 13, 2016 at 12:29:15 AM >To: CAS Users <[email protected]> >Subject: [cas-user] CAS 5 RC4: /serviceValidate, /samlValidate fail after >initial success > >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 <[email protected]> :: UH Information Technology Services >minutas cantorum, minutas balorum, minutas carboratum desendus pantorum > >-- >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 [email protected]. >To post to this group, send email to [email protected]. >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. -- Baron Fujimoto <[email protected]> :: UH Information Technology Services minutas cantorum, minutas balorum, minutas carboratum desendus pantorum -- 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 [email protected]. To post to this group, send email to [email protected]. 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/20161013035355.GF23083%40praenomen.mgt.hawaii.edu. For more options, visit https://groups.google.com/a/apereo.org/d/optout.
