Juan,
I always start with
<logger name="org.jasig">
<level value="DEBUG" />
</logger>
Get everything into the log, then focus on things of interest. e.g
<!-- at DEBUG prints Adding ticket to cache -->
<logger name="org.jasig.cas.ticket.registry" additivity="false">
<level value="DEBUG" />
<appender-ref ref="console" />
</logger>
Ray
On Thu, 2016-01-14 at 15:03 +0000, Juan Quintanilla wrote:
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!
___________________
Juan Quintanilla
UTS - Enterprise Group
305-348-6573
[email protected]<mailto:[email protected]>
________________________________
From: [email protected] <[email protected]> on behalf of Christopher Myers
<[email protected]>
Sent: Thursday, January 14, 2016 9:05 AM
To: [email protected]
Subject: Re: [cas-user] Re: CAS Intermittent SSO logins issues
Out of curiosity, what happens if you take the load balancer out of the picture
- does the required re-authentication happen? Also, do you have any kind of
session replication set up between your CAS nodes, such as hazelcast? Also,
what frequency does this happen? Eg., if someone logs into a CAS application,
then immediately into another application? Or is there some delay in between
the login attempts?
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 <[email protected]> 01/14/16 7:29 AM >>>
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]>
___________________
Juan Quintanilla
UTS - Enterprise Group
305-348-6573
[email protected]<mailto:[email protected]>
________________________________
From: [email protected] <[email protected]> on behalf of Juan Quintanilla
<[email protected]>
Sent: Wednesday, January 13, 2016 8:33 PM
To: [email protected]
Subject: [cas-user] CAS Intermittent SSO logins issues
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.
___________________
Juan Quintanilla
UTS - Enterprise Group
305-348-6573
[email protected]<mailto:[email protected]>
--
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]<mailto:[email protected]>.
Visit this group at
https://groups.google.com/a/apereo.org/group/cas-user/<https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_a_apereo.org_group_cas-2Duser_&d=AwMFaQ&c=1QsCMERiq7JOmEnKpsSyjg&r=NauC5-J1X4CCd25sdSxQCA&m=ln1EbsiEzl4LQiMHly2iyH5O241FsKou2bix9oGIOwM&s=5V8H2qUDQamw54CK9TDzjWXoQHPQO25X_3Om6nWl1Tg&e=>.
--
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]<mailto:[email protected]>.
Visit this group at
https://groups.google.com/a/apereo.org/group/cas-user/<https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_a_apereo.org_group_cas-2Duser_&d=AwMFaQ&c=1QsCMERiq7JOmEnKpsSyjg&r=NauC5-J1X4CCd25sdSxQCA&m=TMEGG5miMUVhMDgjRH7hT-xl6qqs2EFm_mjOB7yZFyw&s=lbzvNWyPiBCKezrBJ60K0FWGLDPc_EvbmCbREKOTXDs&e=>.
--
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]<mailto:[email protected]>.
Visit this group at
https://groups.google.com/a/apereo.org/group/cas-user/<https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_a_apereo.org_group_cas-2Duser_&d=AwMFaQ&c=1QsCMERiq7JOmEnKpsSyjg&r=NauC5-J1X4CCd25sdSxQCA&m=TMEGG5miMUVhMDgjRH7hT-xl6qqs2EFm_mjOB7yZFyw&s=lbzvNWyPiBCKezrBJ60K0FWGLDPc_EvbmCbREKOTXDs&e=>.
--
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].
Visit this group at https://groups.google.com/a/apereo.org/group/cas-user/.
