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)來保證各應用的統一登錄。