注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

隐龙 为了一生的信念

今日默默沉于水,他日飞腾在九天...

 
 
 

日志

 
 

CAS集群处理  

2014-01-08 14:29:52|  分类: CAS/SSO |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

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对象统一存储,那这个问题就迎刃而解了。

  评论这张
 
阅读(590)| 评论(0)
推荐 转载

历史上的今天

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017