CODEWITHSUNDEEP
javaspringstruts2cassingle-logout
nay
nay

Reputation: 105

CAS for multiple clients of same name on multiple instances

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.

enter image description here

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).

enter image description here

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

Upvotes: 0

Views: 1344

Answers (1)

Petr Bodnár
Petr Bodnár

Reputation: 558

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 JSESSIONID by Java servlets). Therefore, the load balancer has to randomly select the target node.

How to solve the problem

There are generally two possible solutions:

  1. Take care of the the "back channel" logout request propagation to all the other nodes. This mean that either the CAS server, or the given application needs to know addresses of all the other nodes - and pass the request to them.
  2. Use so called "front channel" instead of the "back channel" SLO. This means that a slightly modified (GET) logout request is done by the user's browser instead of the CAS server. This implies that the browser passes also the application session identifier with the request and the load balancer can select the correct node for session invalidation this time. With Apereo CAS, this is a matter of telling CAS that front channel should be used in the corresponding CAS service / client application configuration (see their documentation, e. g. for 6.1.x) and using a compatible CAS client in the application.

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:

  1. Stick with CAS 3.x and try to implement solution 1 somehow.

  2. 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

Upvotes: 2

Related Questions