We have two applications (abc and def) were developed in Struts2 and integrated with CAS server 3.2 for SSO, deployed on multiple hosts (IPs). That deployment architecture diagram is below. SSO was working fine with below deployment and there is no issue.
We had deployed the same two CAS clients (abc and def) with multiple instances (tomcat with ports 8080 and 8081) on same host. Please see below deployment architecture diagram for this. With this SSO is not working fine here single sign on working fine but when user logout from abc application (its running on 8081 port of Host2) then session expire request will goes to def application (its running on 8080 port of Host2). With this user is not log out (session is not expired) from def application (its running on 8081 port of Host2).
May be this is stupid question I too do't know. How to resolve this issue. Any one please help me in this. In above two scenarios URL is same http://domain.in/abc/login.do or http://domain.in/def/login.do
Update:
Logout from abc, remains logged in application def.
Looks like you are trying to achieve some kind of cluster here?
Yes. I want to achieve Single logout from all CAS clients. But here its not happening. Logout command is sending to other instance as I described above.
Do you have session replication among the nodes of the same application setup?
Sticky session.
How do you route the traffic from clients (or from CAS) to the individual app nodes?
Load Balancer
On the described load balancing variants
Firstly, it should be noted that it should not really matter if there are 2 or 4 nodes making up the client application cluster. The problem described should happen in any case. Because CAS server always knows and uses just one address of the given client application - the address that points to the load balancer.
Where's the problem
As described, sticky sessions (session affinity) are used for load balancing. And because by default CAS server uses so called "back channel" for Single Log Out (SLO), it makes the (POST) logout request to a given client application itself, without passing any session identifier (the cookie named
JSESSIONIDby Java servlets). Therefore, the load balancer has to randomly select the target node.How to solve the problem
There are generally two possible solutions:
Options for the OP
You are using pretty old CAS version 3.2 - "front channel" SLO doesn't seem to be implemented in the 3.x series. The options are therefore the following:
Stick with CAS 3.x and try to implement solution 1 somehow.
Use solution 2 via:
a) Try to merge the "front channel" SLO from some of the later CAS versions (see below) into CAS 3.x.
b) Upgrade to CAS 4.x and use its "front channel" SLO, "version 1". In this version, CAS relies on synchronous chaining of logout requests - applications are called one by one, each has to redirect the browser back to the CAS, so the CAS can do redirect to the other application in the chain.
c) Upgrade to CAS 5.x or later and use its "front channel" SLO, "version 2". In this version, CAS makes by-default asynchronous Ajax logout requests, which should result in a quicker and more stable SLO.
Further reading