从http验证流程解析CAS单点登录

Posted 2023-02-18

参考技术A JAVA单点登录有好多种方式，譬如用cookie的domain做，用中间代理做等等，但都需要自行做许多开发工作。而其中耶鲁大学的开源项目CAS提供了一个一站式解决方案，只需很少的扩展即可轻松实现企业级单点登录。基础知识网上其他挺多的，这里我就不详述了。本文通过分析http请求过程中http header，cookie等数据剖析了cas（ 非代理模式，默认验证逻辑。其他如restletAPI等可扩展逻辑本文不会覆盖 ）的验证流程，在开发调试中提供了另一种方便的方式掌控整个流程的关键点 。

TGT:  cas服务端生成的每个用户唯一的ticket。

TGC:  cas服务端根据TGT生成的每个用户的cookie,其value是TGT。

ST:    cas服务端根据每个应用，每个用户生成的一个ticket,验证一次就销毁。

Shiro: JAVA权限管理框架

下面将通过两个客户端应用A、B分别跟cas server端交互来详述整个交互流程。本文基于CAS 4.x。 CAS 5.X默认逻辑一致，只不过通过spring boot进行了重新模块划分。

Cas client拦截请求发现session中无cas assertion(其实就是用户名和ticket)并且没有ST则跳转CAS server(本项目由于用了shiro重写拦截逻辑所以是判断shiro中有没有保存验证后的用户信息), server端发现无TGC跳转配置的CAS登陆URL

Response返回302指示重定向。同时可见response返回两个cookie: CASPRIVACY=和CASTGC= TGT-1-MRebCegmlpucavmxcPqCUMVc496IiJgl06BGyJ736D7c4UPkCw-cas01.example.org

也就是说：cas server端验证通过后产生ST并在location URL后面赋给ticket。此时往客户端浏览器写入TGC,并且指示浏览器重定向到location位置，其正是客户端应用验证ST的路径。

此步骤产生2个ticket: TGT,ST;产生一个cookie:TGC,此cookie是通过用户私密信息与TGT加密生成。

此时客户端应用由于受到shiro的保护，request cookie中就不是JSESSIONID而是shiro的SessionId：sid，uuid模式，其与第一步中的sid一致。

Response返回302指示重定向到另一个页面(第一次访问的页面或者shiro配置的successful url)，同时可见生成了新的session和sessionID。同时可见response返回2个cookie:  JSESSIONID,为servlet容器产生的session id，其为location中的jsessionid；rememberMe,为shiro为自动登录配置的。

此步骤验证ST后（通过url connection去cas server验证ST）如果通过则重定向到新页面(第一次访问的页面或者shiro配置的successful url)产生一个新的容器session id。（为何要重新创建session，因为其会在新的session中保存登陆了客户端应用的凭证CAS Assertion,其为客户端验证ST后返回的）到了这步骤以后属于客户端自身的逻辑。CAS作用到此为止。

可以看到这次直接就访问了，也没有经过验证ticket和与cas服务端交互。此是因为session中已经保存了cas assertion，所以算作登陆了。

可见产生了新的shiro session，并提示跳转CAS服务端登陆URL。

可见并没有要求登陆而是直接就提示跳转到location的URL做验证并产生了一个新的ST。这是因为CAS服务端读取了A应用登陆后在浏览器生成的TGC, request cookie中带入了（下图可以看到），从而认为用户已经登陆，所以直接生成ST，并要求重定向到客户端应用B去验证。

步骤同A应用。

如图

如下图：

可见登出时发生四次请求。

直接访问CAS server端的登出url。Cookie中有CASTGC和server端的JSESSIONID。

返回中CASTGC清空，CASPRIVACY清空。 此时说明server端已经清除了A应用的ST和浏览器的CASTGC

跳转到了客户端应用，发现新创建了shiro session（sid）和servlet容器session（JSESSIONID）

并且发现rememberMe和SID的cookie都被换成deleteMe啦。 此为shiro的loginout拦截器干的好事。

正常访问首页，但是因为没登陆所以提示要重定向到CAS服务端去登陆。（如果有了首页就改为跳转到首页）

同原来步骤。

总的来说，cas （非代理模式，默认验证逻辑） 是用一个cookie(TGC), N个session(N个子系统session，其中存储了cas receipt)来保证各应用的统一登录。