JASIG CAS: single sign out not working
Solution 1
I also had another issue with standard CAS protocol, where single sign-out worked on an integration server but not from localhost.
Scenario
- log into both
http://my-app-dev/app
andhttp://localhost:8080/app
with CAS onhttp://my-cas/cas
- log out of CAS
http://my-cas/cas/logout
-
http://my-app-dev/app
now bounces me to CAS -
http://localhost:8080
- still logged in!
I suspect the reason is the CAS server couldn't send a sign-out message to localhost:8080
because localhost
is resolved in the CAS server's context, so it doesn't actually talk to my local dev environment.
Solution 2
I had the same problem. We had a java and a php client. When I went to http://mycasserver/logout
only the java client logged out.
For the single sign out to work in the php client, you have to change:
phpCAS::handleLogoutRequests();
for
phpCAS::handleLogoutRequests(false);
And Voila! Refer to the documentation at phpCAS examples
Solution 3
If you're using SAML 1.1 protocol be sure that you included 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>
Croydon Dias
Updated on June 14, 2022Comments
-
Croydon Dias about 2 years
I have single sign on working beautifully, but single sign-out is not working.
The scenario is like this:
- Open webapp1 and get redirected to CAS login page
- Enter details and login
- Open webapp2 which also uses CAS. Automatically logs in, as the user already signed in.
- Log out of webapp1
- Try to open webapp1 or webapp2 (in another tab) redirects you back to the login page.
- However, the session to webapp2 in step 3 is not closed and the user can still use the application without any problems. How do I automatically invalidate the session when the user signs out?
The log off button for both applications first call
session.invalidate()
and then redirects tohttps://localhost:8443/cas/logout
The single sign out filter is the first filter in the web.xml file. I also have the
SingleSignOutHttpSessionListener
in web.xml.Following is the extract 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>
-
Croydon Dias about 13 yearsBut I do have the SingleSignOutHttpSessionListener in my spring config.
-
Croydon Dias about 13 yearsI have the single sign out listener added to both webapps. I downloaded the source for cas-client-core and added a few debugging statements. It seems that when you logout off webapp1, only the SingleSignOutHttpSessionListener for webapp1 is called, not webapp2.
-
Hons over 12 yearsHave you found the solution in the meantime?
-
Croydon Dias over 12 yearsI have changed jobs since I asked this question. However, we had still not found a proper solution.