前言:
随着用户量的增加以及各种需求的调整,cas的功能免不了需要做各种各样的改造。
简单的:页面维护,样式修改,docker的分环境打包、登陆流程的添加(加个用户信息记录或者添加验证码)。
复杂些的:分布式部署的实现、https改造与多客户端联调。
针对做过的这些改造,下面分篇来讲一讲自己的收获,分享一下遇到的坑以及解决方案。有不对的希望能帮忙指正,希望能给以后处理的人少挖些坑吧。
资源:
CAS( Central Authentication Service)是耶鲁大学的开源项目,旨在实现企业应用单点登录。
其官网 :
https://www.ap ereo.org/
基本概念:
TGC (
Ticket-granting cookie
)
存放用户身份认证凭证的
cookie
,在浏览器和
CAS Server
间通讯
时使用,并且只能基于安全通道传输(Https),是CAS Server用来明确用户身份的凭证。
TGT(
Ticket Grangting Ticket
)
TGT是
CAS
为用户签发的登录票据,拥有了
TGT
,用户就可以证明自己在
CAS
成功登录过。
TGT
封装了
Cookie
值以及此
Cookie
值对应的用户信息。用户在
CAS
认证成功后,
CAS
生成
cookie
(叫
TGC
),写入浏览器,同时生成一个
TGT
对象,放入自己的缓存,
TGT
对象的
ID
就是
cookie
的值。当
HTTP
再次请求到来时,如果传过来的有
CAS
生成的
cookie
,则
CAS
以此
cookie
值为
key
查询缓存中有无
TGT
,如果有的话,则说明用户之前登录过,如果没有,则用户需要重新登录。
ST(
Service Ticket
)
ST是
CAS
为用户签发的访问某一
service
的票据。用户访问
service
时,
service
发现用户没有
ST
,则要求用户去
CAS
获取
ST
。用户向
CAS
发出获取
ST
的请求,如果用户的请求中包含
cookie
,则
CAS
会以此
cookie
值为
key
查询缓存中有无
TGT
,如果存在
TGT
,则用此
TGT
签发一个
ST
,返回给用户。用户凭借
ST
去访问
service
,
service
拿
ST
去
CAS
验证,验证通过后,允许用户访问资源。
大体流程:
事实上当大家对spring-webflow有了解以后看,查看src\main\webapp\WEB-INF\
login-webflow.xml,就可以自己把这个流程图画出来了。对应的登出流程就在src\main\webapp\WEB-INF\
logout-webflow.xml下面。
需要注意一下几点:
关于流程
1、app端有session时,无需再次请求cas服务端(实线部分的流程即可)。
2、app端有st,则直接校验即可(无须重定向到cas服务端获取st)。
3、只有当1、2都不满足,或者校验不通过时,才会唤起输入用户名和密码的页面。
4、cas是集成了spring-webflow的,而对应的信息又保存在cas_server端的session中。所以要分布式部署的话,不能忘了session的共享。
关于票据
1、TGC (Ticket-granting cookie),是存放在浏览器中的,从它是名字就能判断出来。
2、包含用户信息的session保存在app服务端和cas的服务端
3、TGT(Ticket-granting
Ticket),ST(Service Ticket)存放在cas服务端中。要实现上图的分布式部署,将其存入共用的数据库即可。