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

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进行了重新模块划分。

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

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. 客户端应用页面

http request:

Get  http://uc.54315.com/getUcUserRegister

http response:

200 OK

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

1. 访问B应用首页

http request:

Get  http://localhost:8080/

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应用首页

如图

如下图：

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

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:

Get http://uc.54315.com/



http response:

302 Found

Location: https://passport.jzt.com/login?service=http://uc.54315.com/casuc

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

4. 第四次请求

同原来步骤。

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