CAS with Ajax on timed out ticket
Jonathan Labin
Juan Quintanilla
Hi,
We are running CAS 3.6.0 and its been working fine but on occasions we are seeing issues where a user logs into a CAS application and then goes to another CAS application and is prompted to log in again. The applications are not configured to renew or force a new login.
The 2 CAS servers point to the same oracle database and running tomcat 8 both having the same configuration.
We see this more consistent on the first CAS server during tomcat startup where if we point an application to the 1st CAS server directly we are forced to login to each application no matter if we have set a CAS Session. Once the server is restarted again the issue goes away.
This time we see it very intermittently so we are not sure where to look, the second CAS server does not seem to have the issue, but like I said they have the same config and after a tomcat restart its fine.
Any help would really be appreciated.
Jacques Emmanuel Babarit
i had the same issue, what i did is add a specific header to every request coming from the CAS Server and add an interceptor in ajax calls. If the status is 200 and the header is present it means the ajax call has been redirected.
it works in my case, maybe there is a better solution.
J-Emmanuel
--
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.
Visit this group at https://groups.google.com/a/apereo.org/group/cas-user/.
Jonathan Labin
Juan Quintanilla
So wanted to send an update, it seems that the intermittent SSO issue also happened on our Second CAS server today. Once it was rebooted it seemed to not prompt the user to log in again to a CAS application once they had already authenticated to another
CAS application. Below is a snippet from the logs showing ldap authentication request for each service even though I was already authenticated in the first service. When I took a look at the audit logs it seems that its generating a new TGT for each service,
so for some reason CAS was not recognizing that a TGT already existed for the user. The client applications point to a load balanced address which directs the traffic to either of the 2 CAS servers using sticky sessions, I was able to consistently reproduce
the issue so after stopping tomcat 8 and rebooting the server it started working again.
2016-01-14 07:27:33,286 INFO [org.jasig.cas.authentication.AuthenticationManagerImpl] - <Resolved principal testact>2016-01-14 07:27:33,287 INFO [org.jasig.cas.authentication.AuthenticationManagerImpl] - <org.jasig.cas.adaptors.ldap.BindLdapAuthenticationHandler@2f4e8fcd
authenticated testact with credential [username: testact].>
2016-01-14 07:27:33,298 INFO [org.jasig.cas.CentralAuthenticationServiceImpl] - <Granted service ticket [ST-152455-TIaEn95bgajMf4ux46KO-testcas.fiu.edu] for service [https ://testsite1.fiu.edu/] for user [testact]>
2016-01-14 07:28:22,804 INFO [org.jasig.cas.authentication.AuthenticationManagerImpl] - <org.jasig.cas.adaptors.ldap.BindLdapAuthenticationHandler successfully authenticat ed [username: testact]>
2016-01-14 07:28:22,902 INFO [org.jasig.cas.authentication.AuthenticationManagerImpl] - <Resolved principal testact>
2016-01-14 07:28:22,903 INFO [org.jasig.cas.authentication.AuthenticationManagerImpl] - <org.jasig.cas.adaptors.ldap.BindLdapAuthenticationHandler@2f4e8fcd authenticated testact with credential [username: testact].>
2016-01-14 07:28:22,912 INFO [org.jasig.cas.CentralAuthenticationServiceImpl] - <Granted service ticket [ST-152461-1GbGPNwN7KSiPdvZDejk-testcas.fiu.edu] for service [https ://testsite2.fiu.edu/] for user [testact]>
2016-01-14 07:29:59,697 INFO [org.jasig.cas.authentication.AuthenticationManagerImpl] - <org.jasig.cas.adaptors.ldap.BindLdapAuthenticationHandler successfully authenticat ed [username: testact]>
2016-01-14 07:29:59,795 INFO [org.jasig.cas.authentication.AuthenticationManagerImpl] - <Resolved principal testact>
2016-01-14 07:29:59,795 INFO [org.jasig.cas.authentication.AuthenticationManagerImpl] - <org.jasig.cas.adaptors.ldap.BindLdapAuthenticationHandler@2f4e8fcd authenticated testact with credential [username: testact].>
2016-01-14 07:29:59,803 INFO [org.jasig.cas.CentralAuthenticationServiceImpl] - <Granted service ticket [ST-152473-c0Vy6l1X9lTZGxk0uPb4-testcas.fiu.edu] for service [https ://testsite3.fiu.edu/login] for user [testact]>
Sent: Wednesday, January 13, 2016 8:33 PM
To: cas-...@apereo.org
Subject: [cas-user] CAS Intermittent SSO logins issues
Christopher Myers
Some things to check:
Session timeout in your web.xml file:
<session-config>
<!-- Default to 5 minute session timeouts -->
<session-timeout>5</session-timeout>
</session-config>
If there is more of a delay than X minutes in between logins, the users will have to re-authenticate. We have ours set to 120 (2 hours.)
If your URL has "&renew=true" then this will always be the case; that forces the user to re-authenticate to CAS regardless of their current session status. This option can also be forced through your service registry, so you'll want to check that as well.
Also, you may want to kick up your logging to DEBUG for additional details about what's going on during the login process.
Cookies working correctly too?
Ultimately to me, since "I was able to consistently reproduce the issue so after stopping tomcat 8 and rebooting the server it started working again." it sounds like one of your two boxes may be having an issue, because at that point, the connections should be failing over to the other one.
Chris
>>> Juan Quintanilla <jqui...@fiu.edu> 01/14/16 7:29 AM >>>
Juan Quintanilla
Hi,
thanks for your response. We are using tomcat for the session replication and all the Tickets are stored Oracle Db which both CAS servers access. When we have encountered the issue the user hits the same CAS Server during all the login attempts because of the
sticky sessions. Its happened on both our CAS servers when we have stopped tomcat 8 for a while and start it up again, but once we reboot again it seems to goes away, if I took the load balancer out of the loop and configured the client applications to hit
one of the CAS servers having the issue I also encounter the problem.
Our session time out in our web.xml is set to 5 minutes but all the attempts were made within the 5 minutes so there was really no delay between the attempts. We have verified with the client applications that they are not using the renew=true and have SSO set in the service registry. Its just strange that it happens during startup and fixed when we restart tomcat again.
What triggers in the log4j.xml would be best for troubleshooting why the login attempts are forced, its almost as if the TGT is not stored in the browser or can't be verified.
thanks!
Sent: Thursday, January 14, 2016 9:05 AM
To: cas-...@apereo.org
Subject: Re: [cas-user] Re: CAS Intermittent SSO logins issues
