聊聊單點登錄(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 登出成功

標籤：其他

上一篇：Webpack與Vite熱更新差異對比

下一篇：【面試題】JS改變this指向的三種方法