Implement CAS Single Sign Out for Cross Domain Applications - single-sign-on

Question

I am a beginner in using CAS. My CAS server is up and running at port 8443(Secured HTTP layer). I have also made two applications - JAVA Client(My own JAVA Client) and PHP Client(Officially provided by CAS) for testing my CAS server. I am able to use single Sign On for both of the clients. I have also enabled Single Sign Out in the CAS properties file. My current version of CAS is 4.0.0 and I am using Apache Tomcat version 8.0.23
I have added the following dependency for Sign Out in web.xml for JAVA Client
<filter>
<filter-name>CAS Single Sign Out Filter</filter-name>
<filter-class> org.jasig.cas.client.session.SingleSignOutFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>CAS Single Sign Out Filter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
<listener>
<listener-class> org.jasig.cas.client.session.SingleSignOutHttpSessionListener</listener-class>
</listener>
But while performing Single Sign Out, When I log out of PHP Application I am unable to log out of already opened JAVA Applications. This means that on logging out from PHP application does not destroy my existing JAVA Application Sessions.
So after a lot of research I came across this and I was successfully able to implement Sign Out feature. But I do not want to use a common session database.
In the official documentation of CAS it is mentioned that:
CAS sends an HTTP POST message directly to the service ( back channel communication): this is the traditional way of performing notification to the service.
When CAS is configured for SLO, it attempts to send logout messages to every application that requested authentication to CAS during the SSO session.
But I am unable to understand how to fetch the SLO message as I do not receive any POST request( while tracking using firebug) during logout of an application. So Can anyone please help me to perform Single Sign Out.
Thanks in advance.

Answer 1

As found on CAS documentation:
When a CAS session ends, it notifies each of the services that the SSO session is no longer valid, and that relying parties need to invalidate their own session.
This can happen in two ways:
CAS sends an HTTP POST message directly to the service (back channel communication): this is the traditional way of performing notification to the service.
CAS redirects (HTTP 302) to the service with a message and a RelayState parameter (front channel communication): This feature is inspired by SAML SLO, and is needed if the client application is composed of several servers and use session affinity. The expected behaviour of the CAS client is to invalidate the application web session and redirect back to the CAS server with the RelayState parameter.
Usage Warning!
Front-channel SLO at this point is still experimental.
(emphasis added by me)
If you do not see corresponding activity on the browser, you are probably using option #1 where POST messages are send on the backend.
SLO is way more complicated than SSO...