你的位置:首页 > Java教程

[Java教程]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.

 

完成这两部配置,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中,进而保证后续使用正常。