版权声明:转载时请以超链接形式标明文章原始出处和作者信息及本声明
http://fallenlord.blogbus.com/logs/36905130.html
最近忙死了,很久都没写博客了。公司要做SSO应用,有部门有需求希望能够在自己的应用端定义登陆页面,而不是登陆全跳转到CAS统一登陆界面。看了下CAS服务器端源码,还算好懂,于是脱了衣服开始搞。。。。。
这篇主要是介绍修改原理等,如果嫌麻烦,可以跳过这篇直接看实现篇
两个方案,分别支持客户端使用iframe+js和重定向技术进行远程登录,在此先 给出重定向技术的方案。
此方案主要是通过页面重定向来实现客户端独立登陆页面
基本原理
首先,在我们修改之间,先了解以下CAS运行基本原理。CAS服务器,客户端(应用),浏览器的序列图如下:
其中:
- ST:Service Ticket,用于客户端应用持有,每个ST对应一个用户在一个客户端上
- TGT:Ticket Granting Ticket,存储在CAS服务器端和用户cookie两个地方
CAS服务器持有ST与TGT+客户端的映射关系,客户端持有ST与用户Session的映射关系,在renew的情况下,每次客户端根据用户Session将ST发送给CAS服务器端,服务器端检验ST是否存在即可知道此用户是否已登陆。在普通情况下,用户第一次登陆应用时,客户端将用户页面重定向到CAS服务器,服务器取出用户cookie中的TGT,检验是否在服务器中存在,若存在则生成ST返回给客户端 (若不存在则要求登陆,登陆成功后同样返回ST给客户端),客户端拿到ST后再发送给CAS服务器认证是否为真实ST,认证成功即表示登陆成功
我们可以看到,其实我们需要做的就是第2步中返回的登陆页面由服务器改放到客户端,然后让第3步中由用户在客户端上输入用户名密码但提交到CAS服务器端,登陆成功与失败都将转向客户端。
服务器详细登陆流程
对于上一节讲述的整体登陆流程,CAS 3.3.1服务器端上是依赖于Spring Webflow 1.0.3实现的,其主要流程在/WEB-INF/login-webflow.xml中配置,配置的页面流活动图如下(有删节):
图中命名均按照webflow配置文件中的命名,图解如下:
- Action State图标表示webflow配置文件中的action-state或view-state节点
- Decision图标表示webflow配置文件中的decision-state节点
- Initial State图标表示webflow配置文件中的start-state节点
- Final State图标表示webflow配置文件中的end-state节点
登陆的流程依照图上说明,在此不再累述,下面简单说明下CAS服务器端Spring Webflow的运作
首先CAS在/WEB-INF/web.xml中配置命名为cas的servlet以拦截输入请求,若不在cas servlet mapping范围内的资源路径请求均转向到/login上:
所有映射到cas servlet上的请求都将经过/WEB-INF/cas-servlet.xml检查确定进入哪个Action,cas-servlet.xml中最重要的两个bean就是handlerMappingB和handlerMappingC
handlerMappingB配置了登陆流程进入的路径映射,而handlerMappingC则配置了其他的流程的路径映射。/WEB-INF/login-webflow.xml流程配置文件即是在handlerMappingB中通过/login映射进入的。
Webflow依据一个生成的flowExecutionKey来确定一个流程实例走到了哪一步,每次页面流程运转总是需要提交这个flowExecutionKey来告诉webflow它是从流程的哪个位置出发的有了以上理论作为依据,我们在下一节就可以根据自己的需要修改流程,使之支持远程登录了
服务器登陆流程修改目标
修改后的登陆流程活动图如下:
图中橙色为我们修改的流程节点,这里我们增加了一个开始节点remoteLogin和一个结束节点
remoteCallbackView,删除了原有的loginFormView节点、 viewGenericLoginSuccess以及
renew节点(renew节点由于系统无此需求而删除),然后将所有这些节点的转向全部都转向
到remoteCallbackView节点,因为登陆和显示登陆成功信息都应该是客户端完成的
好了,原理到这里已经啰嗦完了,下一节讲如何着手修改CAS服务器端啦