CAS总结之集群环境篇

CAS的集群环境，包括CAS的客户应用是集群环境，以及CAS服务本身是集群环境这两种情况。在集群环境下使用CAS，要解决两个问题，一是单点退出时，CAS如何将退出请求正确转发到用户session所在的具体客户应用服务器，而不是转发到其他集群服务器上，二是解决CAS服务端集群环境下各种Ticket信息的共享。下面依次讨论在这两种集群环境下，CAS的使用情况。

一 客户应用是集群环境

 

集群配置：几台Apache服务器+几台Resin服务器

我们分三种场景依次来讨论一下。

 

1：正常登录

 

登录流程

 

      正常登录过程，如上图所示。CAS客户应用和CAS服务之间是redirect，CAS将请求redirect回客户应用时，浏览器会把客户应用的sessionid(以cookie的形式)顺便带给客户应用，客户应用的集群环境，会根据sessionid,将用户请求始终转发到某一台具体的服务器上。正常登录过程是没有问题的。

 

2：用户正在访问的客户应用服务器宕掉

     当用户正在访问的客户应用服务器宕掉时，集群环境会把用户的下次请求转发到另一台服务器上。如果各服务器之间实现了session共享，那部署在客户应用的CAS Filter是不会再redirect 到CAS去登录的，如果各服务器没有实现session共享，session信息丢失了，那CAS Filter会redirect 到CAS去登录，然后把用户信息加载到本机器的session里。在这种场景下，也是没问题的。

 

3：单点退出

      在退出的时候，客户应用负责redirect到CAS的logout接口，logout接口首先将服务端的TGT对象失效掉，然后遍历TGT对象的services属性（HashMap<String,Service>类型），对于每个Service对象，调用其logOutOfService方法，在此方法中，通过HttpURLConnection访问Service的originUrl属性标识的URL，客户应用端的SingleSignOutFilter截获此请求，将本地的session失效掉，从而达到单点登录的效果。

      这里就有个问题了，Service的originUrl属性的值是CAS客户应用第一次redirect 到CAS时，传来的service参数的值，如http://cms.company.com。CAS通过HttpURLConnection访问http://cms.company.com时，客户应用的集群环境如何知道该把请求转发到哪台服务器上？如果我们什么都不做，那转发到哪台服务器上是随机的，这样的话，客户应用的session就不可能销毁。

      对于这个问题，我的解决办法是对CAS做了一定的修改。在客户应用第一次redirect到CAS时，我在service参数里加上了客户应用的sessionid值，如：https://cas.company.com?service=http://cms.company.com;jsessionid=.......。这样，CAS服务端生成的Service对象的originUrl属性的值就等于http://cms.company.com;jsessionid=....... 。单点退出时，CAS通过HttpURLConnection访问客户应用时，首先从originUrl中解析出jsessionid的值，然后将其放入HttpURLConnection对象的requestProperty中去，代码如下：

Java代码  

1. String jsessionid = "jsessionid="+WebUtils.extranctJsessionIdFromUrl(url);  
2. connection.setRequestProperty("Cookie",jsessionid);  

 

      这样，客户应用接收到此请求时，会得到sessionid值，然后根据sessionid值，将请求转发到正确的服务器上。这样，就解决了集群问题。

 

二 CAS服务本身是集群环境

      CAS服务是集群环境时，如果我们什么都不做，客户应用第一次redirect到CAS，生成TGT对象的服务器，和后来客户应用为了验证Ticket,而访问的CAS服务器，有可能不是一台，这样的话，肯定会失败。如果我们使用memcached这样的集群缓存插件，将TGT、ST对象统一存储，那这个问题就迎刃而解了。