cas工做原理浅析与总结

CAS（ Central Authentication Service ）是 Yale 大学发起的一个企业级的、开源的项目，旨在为 Web 应用系统提供一种可靠的单点登陆解决方法（属于 Web SSO ）。
其流程用时序图描述以下：

1. 请求app地址http://www.app.com
2. app端(cas client)AuthenticationFilter中校验session中_const_cas_assertion_，不为空，直接放过url；不然获取request中的ticket参数，request中无ticket，302重定向到cas server地址，url中带上service参数http://www.casserver.com/?ser...://www.app.com
3. cas server先判断context中是否有service对应的TGT
4. 判断没有TGT，返回login form（客户端跳转至cas server登陆页地址）
5. 用户输入登陆信息，form提交至cas server
6. cas server验证登陆信息，生成TGT和ST
7. 设置TGC至cookie，url中显式带上ticket（STid）参数，重定向Browser至App
8. App中AbstractTicketValidationFilter 会向cas server请求校验ticket，带上ticket（STid）和service（回调地址）参数
9. cas server经过ServiceValidateController校验ticket
10. 确认有效后返回校验成功
11. 此时App中会根据成功结果，在session中设置_const_cas_assertion_属性
12. 重定向到app，此时url中不带有ticket参数
13. 这时再通过AuthenticationFilter时，session中有_const_cas_assertion_属性，放行；再通过AbstractTicketValidationFilter时，request中没有ticket参数，放行，访问目标资源
14. 返回目标资源给browser

要点以下：

1. 如若第4步中，判断结果为有service对应的TGT，先验证ticket（TGTid）、service是否合法，再根据renew参数看是否要从新建立service ticket，若要从新建立，则须要从新登陆；不然从新转向service地址
2. 如若app端想使用本身的自定义登陆界面，能够在第4步中不跳转cas server的登陆页地址，转而跳转至自定义登陆页面。但须要向cas server端请求login ticket，在用户填写登陆表单后，连同login ticket一同传参至cas server去作校验
3. 第6步中，TGT和ST的生成规则（这里指TGTid和STid的生成规则，TGT和ST均为类）："TGT_XX_RandomStr" "ST_XXX_RandomStr"。XX、XXX为AtomicLong.getAndIncrement()方法自增Long类型数字（最大值时，调用AtomicLong.compareAndSet()方法置0）；RandomStr为随机字符串
4. 步骤12中再已校验完用户信息的状况下，再次进行重定向的目的，是为了隐藏第7步重定向时url中的ticket入参
5. 单点登陆的目的，是让用户登陆App1后，若有权限，可免登陆，直接访问App二、App3等。cas的实现方式，是在访问其余App时，使用Cas Proxy。实现原理是App1先经过Cas Server的认证，而后向Cas Server申请一个针对于App2的proxy ticket，以后在访问App2时把申请到的针对于App2的proxy ticket以参数ticket传递过去。后面的流程与上述cas流程步骤8及之后步骤相似