JASIG CAS: single shutdown does not work

Question

I have a single sign of work, great, but a single exit does not work.

The scenario is as follows:

• Open webapp1 and go to the CAS login page.
• Enter data and log in
• Open webapp2, which also uses CAS. Automatically logs in when the user is already logged in.
• Exiting webapp1
• Try opening webapp1 or webapp2 (in another tab) redirects you to the login page.
• However, the webapp2 session in step 3 is not closed, and the user can still use the application without any problems. How to automatically cancel a session when a user logs out?

The logout button for both applications first calls session.invalidate() and then redirects to https://localhost:8443/cas/logout

The single output filter is the first filter in the web.xml file. I also have a SingleSignOutHttpSessionListener in web.xml.

The following is an excerpt from my web.xml

 <!-- CAS settings --> <!-- Use filter init-param if your container does not support context params. CAS Authentication Filter and CAS Validation Filter need a serverName init-param in lieu of a context-param definition. --> <context-param> <param-name>serverName</param-name> <param-value>https://localhost:8443</param-value> </context-param> <!-- Facilitates CAS single sign-out --> <listener> <listener-class>org.jasig.cas.client.session.SingleSignOutHttpSessionListener</listener-class> </listener> <!-- CAS client filters Single sign-out filter MUST come first since it needs to be evaluated before other filters. --> <filter> <filter-name>CAS Single Sign Out Filter</filter-name> <filter-class>org.jasig.cas.client.session.SingleSignOutFilter</filter-class> </filter> <filter> <filter-name>CAS Authentication Filter</filter-name> <!-- IMPORTANT: Use Saml11AuthenticationFilter for version 3.1.12 and later. Use org.jasig.cas.client.authentication.AuthenticationFilter for previous versions. --> <filter-class> org.jasig.cas.client.authentication.Saml11AuthenticationFilter</filter-class> <init-param> <param-name>casServerLoginUrl</param-name> <param-value>https://localhost:8443/cas/login</param-value> </init-param> <init-param> <param-name>service</param-name> <param-value>https://localhost:8443/JAdaptiv/default.action</param-value> </init-param> </filter> <filter> <filter-name>CAS Validation Filter</filter-name> <filter-class> org.jasig.cas.client.validation.Saml11TicketValidationFilter</filter-class> <init-param> <param-name>casServerUrlPrefix</param-name> <param-value>https://localhost:8443/cas</param-value> </init-param> <init-param> <param-name>redirectAfterValidation</param-name> <param-value>true</param-value> </init-param> <init-param> <!-- Leniency of time checking in ms when validating SAML assertions. Consider setting this parameter more liberally if you anticipate system clock drift on your application servers relative to the CAS server. The default is 1000 (1s) and at least one person had problems with drift at that small a tolerance value. A good approach is to start low and then increase by 1000 as needed until problems stop. Note that increasing this value may have negative security implications. Consider fixing clock drift problems as an alternative. --> <param-name>tolerance</param-name> <param-value>1000</param-value> </init-param> </filter> <filter> <filter-name>CAS HttpServletRequest Wrapper Filter</filter-name> <filter-class> org.jasig.cas.client.util.HttpServletRequestWrapperFilter</filter-class> </filter> <filter> <filter-name>CAS Assertion Thread Local Filter</filter-name> <filter-class>org.jasig.cas.client.util.AssertionThreadLocalFilter</filter-class> </filter> <filter-mapping> <filter-name>CAS Single Sign Out Filter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping> <filter-mapping> <filter-name>CAS Authentication Filter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping> <filter-mapping> <filter-name>CAS Validation Filter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping> <filter-mapping> <filter-name>CAS HttpServletRequest Wrapper Filter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping> <filter-mapping> <filter-name>CAS Assertion Thread Local Filter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping> 

Answer 1

I had the same problem. We had java and php client. When I went to http://mycasserver/logout , only the java client came out.

For the only way out to work in the php client you need to change:

 phpCAS::handleLogoutRequests(); 

for

 phpCAS::handleLogoutRequests(false); 

And voila! See documentation for phpCAS examples

Answer 2

If you use the SAML 1.1 protocol, make sure that you enable the artifactParameterName parameter

https://wiki.jasig.org/display/CASC/Configuring+Single+Sign+Out

 <filter> <filter-name>CAS Single Sign Out Filter</filter-name> <filter-class>org.jasig.cas.client.session.SingleSignOutFilter</filter-class> <init-param> <param-name>artifactParameterName</param-name> <param-value>SAMLart</param-value> </init-param> </filter> 

Answer 3

I also had another problem with the standard CAS protocol, where single sign-on worked on the integration server, but not with localhost.

Scenario

• login to both http://my-app-dev/app and http://localhost:8080/app from CAS to http://my-cas/cas
• exit CAS http://my-cas/cas/logout
• http://my-app-dev/app now bounces me to CAS
• http://localhost:8080 - still registered!

I suspect the reason is that the CAS server was not able to send an exit message to localhost:8080 , because localhost allowed in the context of the CAS server, so it does not actually talk to my local dev environment.

Answer 4

I had basically the same configuration for my application before I switched to spring configuration. I looked at SVN, and basically the only difference with your configuration is using Single Sign Out List

 listener> <listener-class>org.jasig.cas.client.session.SingleSignOutHttpSessionListener</listener-class> </listener> 

Could this work for you? Of course, be sure to add it on both WebApps if it works.

UPDATE: I found the listener description in docs and it should do what is missing in your setup

Answer 5

You need to make sure that the CAS server can send an HTTP request to your webapp. Look in the CAS server logs.