CAS cluster deployment session sharing configuration, cas cluster deployment session

CAS cluster deployment session sharing configuration, cas cluster deployment session
Background

Some time ago, the project planned to establish an independent logon Authentication center. Because a set of stable logon and Authentication code was developed separately, the final solution was to apply the Central Authentication Service (CAS) to the open-source Authentication center) for adaptive modification.

In practical applications, for load and Disaster Tolerance considerations, web services are deployed in clusters (usually tomcat clusters). Therefore, the CAS server cluster deployment is required. To deploy CAS clusters, you need to solve two problems:

• CAS Bill sharing, including ST and TGT
• Tomcat session sharing

Tomcat session sharing is required, which is introduced by the spring webflow framework. CAS starts from version 3.x and uses the Spring Webflow framework. This framework needs to store some process identifiers in Tomcat session. By default, session sharing is not implemented for tomcat under the configuration. Therefore, some technical means are required to complete session sharing for tomcat. This article summarizes the usage of tomcat-redis-session-manager for tomcat session sharing.

Running Environment: jdk_6 and tomcat7

Session sharing Configuration

Tomcat session sharing is implemented using third-party plug-ins and tomcat-redis-session-manager. As the name suggests, this solution stores tomcat session in redis (key value DB.

Complete the following configurations:

• The jar package is added to the lib directory of tomcat software. If the runtime environment is inconsistent, you can download the appropriate tomcat-redis-session-manager package in this url (https://github.com/jcoleman/tomcat-redis-session-manager/downloads.

Commons-pool-1.5.5.jar

Jedis-2.1.0.jar

Tomcat-redis-session-manager-1.1.jar

• Modify the context. xml configuration file under the tomcat conf directory, and add the value and manager Configuration segments. MaxInactiveInterval indicates the session storage duration, measured in seconds.

 

After completing these two configurations, tomcat will put the session in redis.

Session not updated problem/SOLUTION Surface symptom

On the cas login page, click Submit/log on to refresh the page. There is no real form submission or verification of the entered username and password.

Cause Analysis

------------------------------------------------ ** CAS background knowledge **--------------------------------------------------

If you have read the CAS server source code, you will know that the CAS login page will submit the three attributes to the CAS server Background:

Where _ eventId and lt are used by CAS's business logic,

Excetion is used by Spring webflow framework to determine whether to initialize a new cas login webflow instance based on excetion. If the input execution is valid, it enters the previous business flow. If the imported execution is invalid, a new webflow will be generated and a new execution will be generated.

 

------------------------------------------------ ** CAS background knowledge **--------------------------------------------------

Redis stores tomcat session information. The "excetion" element on the CAS logon page is not updated when the page is refreshed multiple times. The default Tomcat session Policy (tomcat session is in memory by default without special configuration). The value of this element changes with the page refreshing.

However, the default session policy of tomcat-redis-session-manager always leads to invalid execution (the author's invalid execution is e2s1 ).

View the source code. webflow obtains the session based on execution and the session cannot be obtained based on the input e2s1, and then generates the execution again. The specific manifestation is to refresh the login page and fail to follow the normal "Verification Form" process.

Check the source code with the problem. The execution is invalid, which may be caused by a problem when webflow generates the execution. View the code that generates this property value

context.assignFlowExecutionKey();flowExecution.assignKey();key = keyFactory.getKey(this);

 

After going through a series of Inner-layer calls, we know that execution is generated based on the attributes of the webflowConversationContainer key in the session. The specific attributes include the following:

 

The execution value is related to the conversationIdSequence (int type) field of the session attribute object. If the conversationIdSequence value is 1, the execution value is e2 -- (conversationIdSequence increases by 1 ). When Execution is generated, the session content changes normally. The conversation with id 2 is added to the webflowConversationContainer attribute, and the session is written to redis.

However, according to the default session policy of tomcat-redis-session-manager, the attributes of webflowConversationContainer, the key is not changed, the value address is not changed, and the session is not updated, the new session content is not written to redis. As a result, the webflowConversationContainer attribute obtained in the next request does not have conversation with id 2, so the cas server determines that execution is invalid. The page is refreshed, but the process is not normal: Form Verification.

Confirm session Not written to redis Steps

L add a filter and add the code session. getAttribute ("webflowConversationContainer"). We can see that the attribute values in the session have indeed changed;

L The session string obtained from redis does not change according to the JSESSIONID as the key.

Solution

L modify the dirty data judgment policy of tomcat-redis-session-manager according to the solution for saving custom Class Object properties during session synchronization.

L You can also add a filter to intercept login requests, add a key as "xxx_flag", and set the value to System. currentTimeMillis () attribute. In this way, tomcat-redis-session-manager determines that your session data has changed and will write new session data to redis, in this way, subsequent use is ensured.