聊聊單點登錄(SSO)中的CAS認證

SSO介紹

背景

• 隨着企業的發展，一個大型系統裏可能包含 n 多子系統, 用户在操作不同的系統時，需要多次登錄，很麻煩，我們需要一種 全新的登錄方式來實現多系統應用羣的登錄，這就是單點登錄 。
• web 系統 由單系統發展成 多系統組成的應用羣 ，複雜性應該由 系統內部 承擔，而不是用户。無論 web 系統內部多麼複雜，對用户而言，都是一個統一的整體，也就是説，用户訪問 web 系統的整個應用羣與訪問單個系統一樣，登錄/註銷 只要1次就夠了

SSO 定義

• SSO（Single sign-on） 即單點登錄，一種對於許多相互關聯，但是又是各自獨立的軟件系統，提供訪問控制的方法
• SSO（Single sign-on） 是比較流行的企業業務整合的解決方案之一。 SSO（Single sign-on） 定義是在多個應用系統中， 用户只需要登錄一次就可以訪問所有相互信任的應用系統

以遊樂場的通票為例：

我們只要買一次通票，就可以玩所有遊樂場內的設施，而不需要在過山車或者摩天輪那裏重新買一次票。在這裏，買票就相當於登錄認證，遊樂場就相當於使用一套 SSO 的公司，各種遊樂設施就相當於公司的各個產品。

類比到各個子系統認證，如圖

SSO 三種類型

• 各子系統在同一個站點下

• 各子系統在相同的頂級域名下

  同一個站點和相同頂級域下的單點登錄是利用了 Cookie 頂域共享的特性。目前數棧都是隻需要在 UIC 的登錄頁面進行一次登錄就可以在各個子應用之間進行跳轉，這種操作源於根據設置 Cookie 中的 domain 為頂級域名。

• 各子系統屬於不同的頂級域

  如果屬於不同的域，不同域之間的 Cookie 是不共享的。怎麼辦？接下來就要説一説 CAS (Central Authentication Service) 流程了，這個流程是 單點登錄 的標準流程

CAS (Central Authentication Service)

CAS 是什麼

Central Authentication Service——— 中央認證服務，是 Yale 大學發起的一個企業級的、開源的項目，旨在為 Web 應用 系統提供一種可靠的 SSO 解決方案。只是 SSO 解決方案的一種，它的流程其實跟 Cookie-session 模式是一樣的，單點登錄等於説是每個子系統都擁有一套完整的 Cookie-session 模式，再加上一套 Cookie-session 模式的 SSO 系統 。

第一次訪問 APP1:

1. 用户訪問 APP1 ，需要登錄的時候會重定向到 CAS Server
2. 在 CAS Server 進行賬號密碼認證， CAS Server 會保存 session ，並生成 sessionId 返回給 SSO Client，SSO Client 寫入當前域的 Cookie ，同時根據 TGT 簽發1個 ST 傳入 APP1
3. APP1 攜帶 ST 向 CAS Server 請求校驗
4. CAS Server 校驗成功後，返回 登錄態給 APPI 服務端
5. APPI 服務端 將 登陸態寫入 session 並生成 sessionId 返回給 APPI Client
6. 之後再做登錄認證，就是同域下的認證了

第一次訪問 APP2:

1. 用户訪問系統 APP2 ，當跳到 SSO 裏準備登錄的時候發現 SSO 已經登錄了，那 SSO 生成一個 ST ，攜帶該 ST 傳入 APP2
2. APP2 攜帶 ST 向 CAS Server 請求校驗
3. CAS Server 校驗成功後，返回 登錄態給 APP2 服務端
4. APP2 服務端 將 登陸態寫入 session 並生成 sessionId 返回給 APPI Client
5. 在這個流程裏， APP2 就不用走登錄流程了

CAS 票據

TGT

CAS Server 創建 TGT ，存在 CAS Server 的 Session 裏面，根據用户信息簽發的

TGC

創建 TGT 的同時，生成 TGC 。通過 CAS Server 的 response header 的 set-cookie 字段設置 TGC ，唯一標識用户身份（ sessionId ) ST

ST

根據 TGT 簽發的 ST ，是 CAS 為用户簽發的訪問某一 service 的票據

CAS 單點登錄(SSO) &  單點登出(SLO)

單點登錄(SSO)

第一次訪問 APP1:

1. 訪問 APP1 服務地址， APP1 請求未通過認證，重定向至 CAS Server 地址。
2. 訪問 CAS Server 地址，發送認證請求，帶上 Cookie 。
3. CAS Server 識別出用户沒有 Cookie 信息，沒有登錄，返回 CAS 登陸頁地址。
4. 用户輸入正確的賬户密碼， CAS Server 用户認證通過，創建 SSO Session 。
5. 重定向回 APP1 的服務地址，並在 cookie 中創建了 CASTGC ， TGC 中包含了 Ticket（TGT） ， TGT 就是 SSO Session 的 key 。
6. 訪問 APP1 的服務地址，並帶上 ST ，客户端拿到 ST 向 CAS Server 進行認證。
7. CAS Server 認證成功，返回響應信息給 APPI
8. APPI 拿到成功的響應後，設置 Session ，並重定向回 APP1 的地址，並設置 Cookie JSESSIONID 。
9. APPI 發起請求，帶上 Cookie 中的信息，其中 JSESSIONID 用來確定當前用户所對應的 session 信息，發送給客户端進行校驗。
10. 客户端使用 JSESSIONID 與 Session 中存儲的數據進行校驗。
11. 校驗通過，返回正確的內容，展示 APP1

第二次訪問 APP1:

1. APPI 發起請求，並帶上 Cookie 中的 JSESSIONID 給 APPI 服務端。
2. APPI 服務端 使用 JSESSIONID 與 Session 中存儲的數據進行校驗。
3. 校驗通過，返回正確的內容，展示 APP1 。

在 APP1 登陸成功的情況下，第一次訪問 APP2:

1. 訪問 APP2 服務地址， APP2 請求未通過認證，重定向至 CAS Server 地址。
2. 訪問 CAS Server 地址，發送認證請求，帶上 TGT 信息。
3. CAS Server 通過 TGT 去查找 SSO 的信息進行認證。
4. 認證通過，生成票據 ST 重定向至 APP2 的服務地址。
5. APP2 服務 攜帶 ST 向 CAS Server 進行認證。
6. CAS Server 認證成功，返回客户端通過的響應。
7. 客户端拿到成功的響應後，設置 Session ，並重定向至 APP2 的地址，並設置 Cookie MOD_AUTH_CAS_S 。
8. APP2 發起請求，帶上 Cookie 中的 MOD_AUTH_CAS_S ，發送給客户端進行校驗。
9. 客户端使用 MOD_AUTH_CAS_S 與 Session 中存儲的數據進行校驗。
10. 校驗通過，返回正確的內容，展示 APP2 。

官方時序圖

單點登出(SLO)

1. 在 APP1 平台 請求退出登錄後, 先在 query 中 攜帶 service 字段 重定向 CAS 登出地址
2. 用户攜帶 service query 字段和 CASTGC 請求到 CAS Server
3. CAS Server 根據 CASTGC 找到 TGT 的信息，刪除 TGT 完成 CAS 的註銷
4. CAS Server 可以在 TGT 中拿到關聯的所有 ST , 根據 ST 找到對應的應用註冊信息，調用其中的 logoutUrl ，把 ST 包裝到 logoutRequest 發送給 APP1
5. APP1 根據 logoutRequest 找到 ST ，查找 Session 中以 ST 為鍵的值刪除，清除登陸狀態
6. APP1 登出成功
7. APP2 根據 logoutRequest 找到 ST ，查找 Session 中以 ST 為鍵的值刪除，清除登陸狀態
8. APP2 登出成功