SSO 單點登陸 ——CAS實現方式

本文大量參考了一篇文章，包括用圖，http://www.coin163.com/java/c...

SSO（Single Sign On）是在多個應用系統中，用戶只需登陸一次就能夠訪問全部相互信任的應用系統。

基礎協議

角色與職責

CAS實現方式有3個角色，用戶瀏覽器，CASClient，CASServer。CASClient對於用戶瀏覽器而言是一個Server，對於CASServer而言是一個Client。用戶瀏覽器是終端用戶，是SSO的使用者，CASClient是前置用戶驗證系統，用於驗證用戶的合法性只有經過了CAS驗證的用戶，才能進一步訪問後邊真正的資源。

驗證過程

1. CASClient與受保護的應用部署到一塊兒，假設CASClientA對應着Web應用A，CASClientB對應Web應用B。

2. 瀏覽器訪問Web應用A，CASClient查看用戶是否登陸過，這裏的一種判斷方式是使用Session保存TK，發現訪問沒有TK或者TK不對就重定向到CASServer。TK的來源在下邊講。

3. 瀏覽器重定向到了CASServer那裏，這裏瀏覽器是帶着CASServe域的Cookie的，CASServer能夠經過Cookie判斷用戶是否登陸過，也就是TGC（來源也在後邊的步驟裏）。發現也沒有登陸過，就返回登陸頁面。

4. 瀏覽器輸入用戶名密碼，CASServer驗證經過後，生成一個惟一的不可僞造的Key，叫作ServiceTicket，簡稱TK。而後，一方面CASServer將這個TK記下來，以備後續的驗證使用，另外一方面，給瀏覽器A設置一個Ticket Granted Cookie，簡稱TGC。而後重定向瀏覽器A到CASClient的地址，帶上參數TK。因此TK和TGC都是CASServer生成的。

5. CASClient收到了TK以後，拿到CASServer那裏去驗證。驗證經過後，CASServer返回用戶相關信息。

6. CASClient拿到用戶信息後，設置Session，而後放請求到業務Server處理。

7. 瀏覽器訪問Web應用B，CASClientB也要檢查用戶是否登陸，發現沒有登陸，將瀏覽器重定向到CASServer。

8. 瀏覽器訪問CASServer的時候，Cookie中是設置了TGC了的，因而CASServer不用返回登陸頁面，直接將TGC對應的TK返回給瀏覽器並重定向到CASClientB，CASClientB向CASClientServer驗證後，拿到用戶信息，設置Session，放行服務。實現了SSO。

更復雜的場景

用戶訪問App1，App1又依賴於App2來獲取一些信息。這種狀況下，App2也是要對用戶身份進行驗證的，本質上可使用屢次重定向實現。即，App1的驗證經過後，訪問App2的服務，還要重定向到CASServer，而後再重定向到App2，而後在重定向回到App1。爲了優化用戶體驗，可使用CAS的代理模式。用CASClient1代理用戶進行App2的身份驗證。

1. 在驗證ST的時候，額外提供一個PGTURL（Proxy Granted Ticket），這個URL入口是SSL的。

2. CASServer回調PGTURL，給CASClient一個PGT串。

3. 須要使用App2資源的時候，CASClient用PGT串到CASServer那裏換取PT，PT是根據PGT和要使用的Service（這裏是App2）來生成的。因此使用不一樣的Service會有不一樣的PT。

4. CASClient用PT訪問App2的資源

5. App2的CASClient拿着PT再去Server那裏驗證權限

6. 驗證經過後將資源返回給App1的CASClient

7. App1提供服務後將數據返回給瀏覽器。

代理認證過程以下：

代理認證的思路和客戶端認證的思路是同樣的，就是返回不一樣的串，增長了一層複雜性。

CAS 系統中設計了 5 中票據： TGC 、 ST 、 PGT 、 PGTIOU 、 PT 。

1. Ticket-granting cookie(TGC) ：存放用戶身份認證憑證的 cookie ，在瀏覽器和 CAS Server間通信時使用，而且只能基於安全通道傳輸（ Https ），是 CAS Server 用來明確用戶身份的憑證；

2. Service ticket(ST) ：服務票據，服務的唯一標識碼 , 由 CAS Server 發出（ Http 傳送），經過客戶端瀏覽器到達業務服務器端；一個特定的服務只能有一個唯一的 ST ；

3. Proxy-Granting ticket （ PGT ）：由 CAS Server 頒發給擁有 ST 憑證的服務， PGT 綁定一個用戶的特定服務，使其擁有向 CAS Server 申請，得到 PT 的能力；

4. Proxy-Granting Ticket I Owe You （ PGTIOU ） : 做用是將經過憑證校驗時的應答信息由 CAS Server 返回給 CAS Client ，同時，與該 PGTIOU 對應的 PGT 將經過回調連接傳給 Web 應用。 Web 應用負責維護 PGTIOU 與 PGT 之間映射關係的內容表；

5. Proxy Ticket (PT) ：是應用程序代理用戶身份對目標程序進行訪問的憑證。

安全性

CAS最重要的是保護TGC的安全性，若是TGC被CASServer之外的實體拿到，那麼若是Hacker找到TGC，就能夠冒充登陸用戶了。因爲TGC是CASServer經過SSL方式發送給終端用戶的，所以截獲的難度至關大，從而能確保CAS的安全性。

ST只能使用一次，因爲ST是HTTP傳輸的，因此是能夠被截獲的，一次CAS協議規定，不管ST的驗證是否成功，CASServer都會清除服務端的ST緩存。從而確保ST不會被使用兩次。CAS還規定，ST只能存活一段時間。而後CASServer就會讓他失效。另外，ST必須足夠隨機。