技術文章 » 聊聊單點登入(SSO)中的CAS認證

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

2022-09-15 21:02:05

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 登出成功