CAS 集群部署session共享配置

背景

前段时间，项目计划搞独立的登录鉴权中心，由于单独开发一套稳定的登录、鉴权代码，工作量大，最终的方案是对开源鉴权中心CAS（Central Authentication Service）作适配修改。

实际应用中，web服务出于负载、容灾的考虑，采用集群部署web服务（一般是tomcat集群），于是有了CAS server端集群部署的需求。CAS集群部署，需要解决两个问题：

• CAS票据共享，票据包括ST、TGT
• Tomcat session共享

需要作tomcat session共享，是由spring webflow框架引入的需求。CAS从3.x的版本开始，使用Spring Webflow框架，该框架需要在Tomcat session中存储一些流程标识。默认配置下的tomcat，没有做到session共享，因此需要使用一些技术手段，来完成tomcat的session共享。本文，即使用tomcat-redis-session-manager作tomcat session共享的一些总结。

运行环境：jdk_6，tomcat7

Session共享配置

采用第三方插件，tomcat-redis-session-manager来实现tomcat session共享。顾名思义，这种方案，是将tomcat session存储到了redis（key value DB）中。

主要完成两部分配置：

• jar包加到tomcat软件的lib目录下，如果运行环境不一致，可在此url（https://github.com/jcoleman/tomcat-redis-session-manager/downloads）中下载适合的tomcat-redis-session-manager包。

　　　　commons-pool-1.5.5.jar

　　　　jedis-2.1.0.jar

　　　　tomcat-redis-session-manager-1.1.jar

• 修改tomcat conf目录下的context.xml配置文件，加上valve和manager配置段。其中maxInactiveInterval是session存储时长，单位是秒。

 

    <Valve className="com.radiadesign.catalina.session.RedisSessionHandlerValve" />
    <Manager className="com.radiadesign.catalina.session.RedisSessionManager" host="ip" port="port" database="0" maxInactiveInterval="second"/>

完成这两部配置，tomcat会把session放到redis中了。

Session不更新问题/解决

表面现象

在cas login页面，点击【提交/登录】按钮，只是刷新该页面，没有真正的表单提交、验证输入的用户名密码的动作。

原因分析

--------------------------------------------------**CAS背景知识 **--------------------------------------------------

看过CAS服务端源码的同学，会知道CAS登录页面会将下图中的三个属性，提交到CAS服务端的后台：

其中_eventId和lt是CAS的业务逻辑使用的，

excetion是Spring webflow框架使用的，作用是根据excetion，来确定是否需要初始化一个新的cas login webflow实例，如果传入的execution有效，进入之前的业务流。如果传入的execution无效，则会初始新的webflow ，并生成一个新的execution。

 

--------------------------------------------------**CAS背景知识 **--------------------------------------------------

redis存储tomcat session情况，CAS登录页面上元素【excetion】，多次刷新页面不更新。Tomcat session默认策略下（不做特殊配置时，tomcat session默认在内存中），该元素的值，会随页面刷新变更。

         而使用tomcat-redis-session-manager默认的session策略，会导致总是传入无效的execution（笔者无效的execution为e2s1）。

         查看源码，webflow根据execution获取会话，根据传入的e2s1，获取不到会话，进而重新生成execution。具体表现是重新刷新登录页面，不能走正常的“验证表单”流程。

         带着问题继续看源码，execution无效，可能是webflow生成execution的时候出了问题。查看生成该属性值代码

context.assignFlowExecutionKey();

flowExecution.assignKey();

key = keyFactory.getKey(this);

 

　　　经历一系列内层调用，知道execution是根据session中key为webflowConversationContainer的属性生成的，具体属性包含以下内容：

 

　　execution的值和session属性对象的字段conversationIdSequence（int类型）相关，如果conversationIdSequence值为1，那execution的值即为e2--（conversationIdSequence自增1）。生成Execution的同时，正常情况session内容也相应变化，webflowConversationContainer属性中新增了id为2的conversation，session写入到redis中。

　　但是，按照tomcat-redis-session-manager默认的session策略，webflowConversationContainer属性，key没有变，value地址没有变，认为session没有更新，新的session内容没有写入到redis中。导致下次请求，取到的webflowConversationContainer属性，没有id为2的conversation，于是cas server端认定execution 为无效。导致刷新页面，而非正常的流程：表单验证。

确认session没有写入redis的步骤

l  增加一个filter，加入session.getAttribute("webflowConversationContainer")这样的代码，可以看到session中的属性值，确实发生了变化；

l  根据JSESSIONID作为key，从redis中取到的session 串没有变化。

解决办法

l  按照《session同步时自定义类对象属性保存不上的解决方法》所述，修改tomcat-redis-session-manager 脏数据判定策略。

l  或者在增加一个filter，拦截login请求，新增一个key为”xxx_flag”，value为System.currentTimeMillis()的属性，这样，tomcat-redis-session-manager认定你的session数据是变化了的，会将新的session数据，写入到redis中，进而保证后续使用正常。