Cluster Environment in CAS Summary

The Cluster Environment of CAS, including the cluster environment for CAS customer applications and the Cluster Environment for CAS services. To use CAs in a cluster environment, we need to solve two problems: first, how does CAS correctly forward exit requests to the specific client application server where the user session is located during single-point exit, instead of forwarding to other cluster servers, the second is to share various ticket information in the CAS server cluster environment. The usage of CAs in these two cluster environments is discussed in sequence.

One customer application is a cluster environment

 

Cluster configuration: several Apache servers and several resin servers

We will discuss it in three scenarios in sequence.

 

1: normal Logon

 

Logon Process

 

Shows the normal logon process. The CAS customer application and CAS service are redirect. When CAS requests redirect back to the customer application, the browser will bring the sessionid of the customer application (in the form of cookie) to the customer application by the way, in the cluster environment of the customer application, user requests are always forwarded to a specific server based on the sessionid. The normal logon process is normal.

 

2: the customer's application server that the user is accessing goes down

When the client application server that the user is accessing goes down, the cluster environment will forward the user's next request to another server. If session sharing is implemented between servers, the CAS filter deployed on the client application will no longer be redirect to CAS for login. If session sharing is not implemented on each server, session information will be lost, CAS filter will redirect to CAs to log on, and then load the user information to the session of the machine. In this scenario, there is no problem.

 

3: single-point exit

When exiting, the customer application is responsible for redirect to the CAS logout interface. The logout interface first invalidates the TGT object on the server, and then traverses the services attribute (hashmap <string, service> type). For each service object, the logoutofservice method is called. In this method, the URL identified by the originurl attribute of the service is accessed through httpurlconnection, And the singlesignoutfilter of the client application intercepts this request, disable the local session to achieve single-point logon.

Here there is a problem, the value of the originurl attribute of the service is the value of the service parameter sent from the CAS customer application for the first redirect to CAS, such as the http://cms.company.com. When CAS accesses the http://cms.company.com through httpurlconnection, how does the cluster environment of the customer application know which server should the request be forwarded? If we do not do anything, It is random to the server to which it is forwarded. In this way, the session of the client application cannot be destroyed.

My solution to this problem is to modify the CAS. When the customer application first redirect to CAS, I added the sessionid value of the customer application to the service parameter, such as: https://cas.company.com? Service = http://cms.company.com; JSESSIONID = ........ In this way, the value of the originurl attribute of the service object generated by the CAS server is equal to the http://cms.company.com; JSESSIONID = ........ When CAS accesses a client application through httpurlconnection, it first parses the value of JSESSIONID from originurl and puts it into the requestproperty of the httpurlconnection object. The Code is as follows:

Java code

1. String JSESSIONID = "JSESSIONID =" + webutils. extranctjsessionidfromurl (URL );
2. Connection. setrequestproperty ("cookie", JSESSIONID );

 

In this way, when the customer application receives this request, it will get the sessionid value, and then forward the request to the correct Server Based on the sessionid value. In this way, the cluster problem is solved.

 

CAS is a cluster environment.

When CAS is a cluster environment, if we do not do anything, the customer's application will redirect to the CAS server for the first time to generate the TGT object, and the CAS server accessed by the customer's application to verify ticket, it may not be one. In this case, it will certainly fail. If we use a cluster cache plug-in such as memcached to store TGT and St objects in a unified manner, this problem will be solved.