从http验证流程解析CAS单点登录
JAVA单点登录有好多种方式，譬如用cookie的domain做，用中间代理做等等，但都需要自行做许多开发工作。而其中耶鲁大学的开源项目CAS提供了一个一站式解决方案，只需很少的扩展即可轻松实现企业级单点登录。基础知识网上其他挺多的，这里我就不详述了。本文通过分析http请求过程中http header，cookie等数据剖析了cas（非代理模式，默认验证逻辑。其他如restletAPI等可扩展逻辑本文不会覆盖）的验证流程，在开发调试中提供了另一种方便的方式掌控整个流程的关键点。
Cas术语
TGT: cas服务端生成的每个用户唯一的ticket。
TGC: cas服务端根据TGT生成的每个用户的cookie,其value是TGT。
ST: cas服务端根据每个应用，每个用户生成的一个ticket,验证一次就销毁。
Shiro: JAVA权限管理框架
Cas请求交互总图
下面将通过两个客户端应用A、B分别跟cas server端交互来详述整个交互流程。本文基于CAS 4.x。 CAS 5.X默认逻辑一致，只不过通过spring boot进行了重新模块划分。
客户端应用A访问跳转Cas Server验证
http request:
GET http://uc.54315.com/myWhListManager
http response:
302 Found
Location: https://passport.jzt.com/login?service=http://uc.54315.com/casuc
Cas client拦截请求发现session中无cas assertion(其实就是用户名和ticket)并且没有ST则跳转CAS server(本项目由于用了shiro重写拦截逻辑所以是判断shiro中有没有保存验证后的用户信息), server端发现无TGC跳转配置的CAS登陆URL
Cas server端登陆后http请求过程
1. post提交用户信息验证：
http request:
Post https://passport.jzt.com/login?service=http://uc.54315.com/casuc
http response:
302 Found
Location:http://uc.54315.com/casuc?ticket=ST-1-0kdGxVoshSZz2Bp6kMaA-cas01.example.org
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加密生成。
2. Cas client验证ST：
http request:
Get http://uc.54315.com/casuc?ticket=ST-1-0kdGxVoshSZz2Bp6kMaA-cas01.example.org
此时客户端应用由于受到shiro的保护，request cookie中就不是JSESSIONID而是shiro的SessionId：sid，uuid模式，其与第一步中的sid一致。
http response:
302Found
Location:http://uc.54315.com/myWhListManager;jsessionid=qqwn1wmrsymy47n8udvf7v2s
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作用到此为止。
3. 客户端应用页面
客户端应用A再次访问
http request:
http response:
200 OK
可以看到这次直接就访问了，也没有经过验证ticket和与cas服务端交互。此是因为session中已经保存了cas assertion，所以算作登陆了。
客户端应用B访问
1. 访问B应用首页
http request:
http response:
302 Found
Location: https://passport.jzt.com/login?service=http://localhost:8080/casuc
可见产生了新的shiro session，并提示跳转CAS服务端登陆URL。
2. 访问CAS服务器登陆URL
http request:
Get https://passport.jzt.com/login?service=http://localhost:8080/casuc
http response:
302 Found
Location: http://localhost:8080/casuc?ticket=ST-2-wtWpPg2Sv4d00fXecLSI-cas01.example.org
可见并没有要求登陆而是直接就提示跳转到location的URL做验证并产生了一个新的ST。这是因为CAS服务端读取了A应用登陆后在浏览器生成的TGC, request cookie中带入了（下图可以看到），从而认为用户已经登陆，所以直接生成ST，并要求重定向到客户端应用B去验证。
3. 验证ST
http request:
Get http://localhost:8080/casuc?ticket=ST-2-wtWpPg2Sv4d00fXecLSI-cas01.example.org
http response:
302 Found
Location: http://localhost:8080/;jsessionid=1jh99lja6wzxw1jweg8ss40yt8
步骤同A应用。
4. 访问B应用首页
如图
客户端应用A退出
如下图：
可见登出时发生四次请求。
1. 第一次请求：
http request:
GET https://passport.jzt.com/logout?service=http://uc.54315.com:80/logout
http response:
302 Found
Location: http://uc.54315.com:80/logout
直接访问CAS server端的登出url。Cookie中有CASTGC和server端的JSESSIONID。
返回中CASTGC清空，CASPRIVACY清空。 此时说明server端已经清除了A应用的ST和浏览器的CASTGC
2. 第二次请求：
http request:
Get http://uc.54315.com/logout
http response:
302 Found
Location: http://uc.54315.com/
跳转到了客户端应用，发现新创建了shiro session（sid）和servlet容器session（JSESSIONID）
并且发现rememberMe和SID的cookie都被换成deleteMe啦。 此为shiro的loginout拦截器干的好事。
3. 第三次请求：
http request:
http response:
302 Found
Location: https://passport.jzt.com/login?service=http://uc.54315.com/casuc
正常访问首页，但是因为没登陆所以提示要重定向到CAS服务端去登陆。（如果有了首页就改为跳转到首页）
4. 第四次请求
同原来步骤。
Cas总结
总的来说，cas（非代理模式，默认验证逻辑）是用一个cookie(TGC), N个session(N个子系统session，其中存储了cas receipt)来保证各应用的统一登录。
