0

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

nay
  • 95
  • 12
  • It's hard to answer this question. I suggest you to debug CAS server libraries to see what happens when user logs out from application. AFAIK after user logout from an app if single sign out filter is activated, CAS Server sends logout command to all other apps. – Mohsen Dec 03 '19 at 09:00
  • @Spara, what's you are telling is exactly correct. CAS server is sending logout command all apps (abc and def). Its ok. But its sending logout command to abc on 8081 and def on 8080. But actually it should be def on 8081. – nay Dec 03 '19 at 10:25
  • Looks like you are trying to achieve some kind of cluster here? I wouldn't be surprised from the described behavior then. How do you route the traffic from clients (or from CAS) to the individual app nodes? Do you have session replication among the nodes of the same application setup? I guess logging out of one node needs to be propagated to the other nodes if you want a working Single Log Out. But that's not a problem to be solved by the CAS server. Maybe just try to describe your problem in a more readable fashion... – Petr Bodnár Dec 03 '19 at 21:23
  • Or, it's likely that you use [sticky sessions](https://stackoverflow.com/questions/10494431/sticky-and-non-sticky-sessions). Then you could try the "Front Channel" as described in the [CAS documentation](https://apereo.github.io/cas/6.1.x/installation/Logout-Single-Signout.html). – Petr Bodnár Dec 03 '19 at 21:55
  • @PetrBodnár How to achieve SLO. I just through the doc in above link. But I didn't understand completely. – nay Dec 04 '19 at 06:04
  • I see, it's not easy. I tried to formulate possible solutions - see my answer... – Petr Bodnár Dec 05 '19 at 00:59

1 Answers1

2

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

Petr Bodnár
  • 496
  • 3
  • 14
  • Thank you! I have downloaded CAS 6 from github repo and trying to build it but getting `A problem occurred evaluating root project 'cas-server'. repository not found: F:\cas-6.0.0`. – nay Dec 05 '19 at 12:36
  • Thank you too :) To your question - Do you try to build CAS [from source](https://apereo.github.io/cas/developer/Build-Process-6X.html)? I haven't tried that yet. Creating your project as a WAR overlay by cloning the [cas-overlay-template](https://github.com/apereo/cas-overlay-template) should work and can be easier... – Petr Bodnár Dec 05 '19 at 16:52
  • Does it compatible with jdk8? In doc I found that it compatible with 11. Whats difference between cas and cas-overlay-template? – nay Dec 06 '19 at 10:00
  • 1
    CAS 6 does not compatible with Java 8, use Java 11 should be fine. `cas` is for development of the entire CAS, while `cas-overlay-template` is for us who just want to use CAS. You should use `cas-overlay-template` – Ng Sek Long Dec 06 '19 at 14:54
  • I've successfully built `cas-overlay-template` war with help of you both. Can you help me `Where can I write my own authentication logic with database connection in CAS`. Not only authentication I need to integrate other logics (like auditing, etc) too. In CAS they are provided static user id and password. – nay Dec 09 '19 at 13:14
  • @nay, congratulations! There are quite dramatic changes in every new major CAS release when talking about configuration. I'm afraid you will have to cope with migrating all your customizations yourself, or you may try asking a new question here on SO, of course :) It may also help a little to update just to 5.x instead to 6.x, but this is really only up to your decision... – Petr Bodnár Dec 09 '19 at 18:25
  • @PetrBodnár I'm trying with CAS 5.x only but it's not working means getting error https://stackoverflow.com/questions/59299110 – nay Dec 12 '19 at 07:53