業務流程分析未載入sso登錄模塊是怎么回事 _經驗分享

01-SSO 業務流程分析
假設，我們有三個系統，分別是單點登錄服務（或者也可稱為是統一認證中心、統一認證服務，CAS）、業務系統 A、業務系統 B 。
場景一，用戶在統一認證中心未登錄條件下，首次訪問業務系統 A；
場景二，用戶在統一認證中心已登錄條件下，再次訪問業務系統 A；
場景三，用戶在統一認證中心已登錄條件下，首次訪問業務系統 B 。
上述三個場景是單點登錄模型中的三個典型場景，接下來我將逐個分析，并給出時序圖。
01.1-場景一和場景二
場景一、場景二是關聯性比較強的場景，所以我放在一起討論。

文章插圖

接下來，我會對圖中流程的關鍵點進行解釋，方便大家理解。步驟 1-3 是用戶首次訪問業務系統 A 時的處理邏輯： A 會先檢查用戶是否登錄，如果未登錄（從技術上講就是用戶請求中沒有攜帶 Session ID，或攜帶的 Session ID 在當前系統中找不到對應的 Session 對象），會檢查請求是否帶有認證中心頒發的臨時令牌。由于未在認證中心登錄的前提條件，請求中也沒有臨時令牌，所以系統 A 就認為用戶尚未登錄，然后會通過重定向的方式告知客戶端去 CAS 進行登錄認證（步驟 4）。
步驟 5-7 是認證服務的邏輯，判斷是否登錄。判斷方式與前面類似，檢查認證中心系統中是否有用戶對應的 Session 對象。這里的 Session 也被稱為全局會話（先記住這個名字），指用戶與認證中心之間建立的會話。如果用戶未登錄，認證中心會提供登錄界面讓用戶登錄（7-9）。登錄成功后，認證中心會創建一個全局會話，并且生成一個臨時令牌（token），通過重定向響應返回給用戶（步驟 11）。
用戶拿到統一認證中心的臨時令牌后，會再次請求業務系統 A 。A 會重復使用步驟 1-3 去檢查用戶的請求，發現尚未登錄、但是請求中帶有臨時令牌（13-14）。然后，它會去認證中心校驗令牌的合法性（15-16）。令牌若合法，系統 A 就知道該用戶在認證中心登錄過了，就會創建一個 Session（這個也被稱為是局部會話），并返回用戶請求的資源（17-18）。
注：從上面的流程中可以發現，全局會話是用戶與認證系統之間的會話，通過登錄這種方式創建的。局部會話是用戶與業務系統之間的，通過校驗臨時令牌的合法性方式創建的。當全局會話失效，它生成的臨時令牌也將失效，基于臨時令牌的局部會話也將全部失效。這就是全局會話、局部會話之間的依存關系。
前面的步驟都是在用戶未在 CAS 登錄前提下，首次訪問業務系統 A 時的處理流程。接下來，我們來一起看下局部會話建立后，用戶再次訪問業務系統 A 時的處理流程。
【業務流程分析未載入sso登錄模塊是怎么回事】因為之前已經建立了與業務系統 A 的局部會話，所以再次訪問 A，驗證是否已登錄時，驗證結果為已登錄。業務系統就會直接返回用戶請求的資源（步驟 20-21）。
01.2-場景三
場景三也是在場景一的基礎上進行的。它的流程圖如下所示：

文章插圖

用戶首次訪問業務系統 B 時，與場景一中的步驟 1-3 是相同的。系統 B 發現用戶未登錄（不存在用戶、B 之間的局部會話），之后檢查用戶是否帶有臨時令牌。這里分為兩種情況：
請求里帶有 token
請求里不帶 token
針對第一中情況，系統 B 會去 CAS 驗證 token 的合法性，若合法，則會創建系統 B 與用戶之間的局部會話，并將用戶請求的資源響應給用戶（步驟 8-14）。
針對第二種情況，系統 B 會重定向用戶請求到 CAS 進行登錄。CAS 收到用戶登錄請求后，檢查發現用戶與 CAS 之間已經存在全局會話，則獲取創建全局會話時一并生成的臨時令牌，并通過重定向響應返回給客戶端。客戶端收到 token 后，攜帶 token 請求系統 B，與處理第一種情況類似。
02-從 HTTP 報文角度分析 SSO 登錄流程
在上一節，我們對 SSO 登錄的業務流程進行了梳理，大致上明白了 SSO 登錄在處理什么問題，處理問題的大致流程是什么。接下來，我將從 HTTP 報文角度，分析一下每個步驟客戶端、業務系統、CAS 認證中心都會接受、發送什么樣的報文，進而更深入地理解 SSO 登錄過程。同樣地，我會按照上節的三個場景逐個分析。
02.1-場景一和場景二中的 HTTP 報文
步驟一，用戶請求業務系統 A 的某個頁面：
GET /users HTTP/1.1
Host: businessa.example.samson.self
復制代碼
步驟四，業務系統 A 驗證用戶發現未登錄，重定向到 CAS 去登錄：
HTTP/1.1 302 Moved Temporarily
Location: http://cas.example.samson.self/login?backurl=http://businessa.example.samson.self/users
復制代碼
瀏覽器重定向請求，獲得登錄界面：
GET /login?backurl=http://businessa.example.samson.self/users HTTP/1.1
Host: cas.example.samson.self
復制代碼
步驟八，用戶提交登錄請求后，CAS 驗證并創建全局會話，再將 token 返回給用戶：
POST /login?backurl=http://businessa.example.samson.self/users HTTP/1.1
Host: cas.example.samson.self
復制代碼
步驟十一，用戶收到重定向響應：
HTTP/1.1 302 Moved Temporarily
Set-Cookie: JSESSIONID=51d5590d-55c0-48cb-bff2-cdab040f687c
Location: http://businessa.example.samson.self/users?authCode=7d227af1-20e5-49bc-829b-b049aaadd56e&username=lihua
復制代碼
步驟十二，帶著令牌訪問業務系統 A：
GET /users?authCode=7d227af1-20e5-49bc-829b-b049aaadd56e&username=lihua HTTP/1.1
Host: businessa.example.samson.self
復制代碼
業務系統驗證令牌合法性后，返回用戶請求的資源（步驟十八）：
HTTP/1.1 200 OK
Set-Cookie: JSESSIONID=baf4765d-3d06-4000-aaa1-44fcb9e2b25f
復制代碼
場景二中，用戶已經與業務系統 A 建立好局部會話，所以再次請求時，可以直接獲得資源：
GET /users HTTP/1.1
Host: businessa.example.samson.self
Cookie: JSESSIONID=baf4765d-3d06-4000-aaa1-44fcb9e2b25f
復制代碼
02.2-場景三中的 HTTP 報文
同樣分兩種情況，對于第一種情況，即不帶令牌訪問：
GET /permissions HTTP/1.1
Host: businessb.example.samson.self
復制代碼
業務系統發送重定向響應（帶有全局會話 SessionID）：
HTTP/1.1 302 Moved Temporarily
Location: http://cas.example.samson.self/login?backurl=http://businessb.example.samson.self/permissions
Cookie: JSESSIONID=51d5590d-55c0-48cb-bff2-cdab040f687c
復制代碼
CAS 系統返回響應：
HTTP/1.1 302 Moved Temporarily
Location: http://businessb.example.samson.self/permissions?authCode=7d227af1-20e5-49bc-829b-b049aaadd56e&username=lihua
復制代碼
客戶端帶著令牌訪問業務系統 B：
GET /permissions?authCode=7d227af1-20e5-49bc-829b-b049aaadd56e&username=lihua HTTP/1.1
Host: businessb.example.samson.self
復制代碼
業務系統驗證令牌合法性，并建立局部會話：
HTTP/1.1 200 OK
Set-Cookie: JSESSIONID=268459a0-3279-4e86-b627-cbe3e3efdf32
復制代碼
針對第 2 種情況，與后面帶著令牌訪問系統 B 是一樣的過程。
03-總結
今天，我介紹了 SSO 登錄過程的一般流程，并通過三個典型場景分析了登錄流程的處理細節。并且，在了解大致業務流程后，從 HTTP 報文的角度分析了各個模塊（客戶端、業務系統、統一認證服務）在每個流程中的一般動作。我只在分析過程中給出了 HTTP 報文的頭部信息。感興趣的小伙伴可以自己動手實現下上述過程，并觀察下整個流程中發送的 HTTP 報文情況，是否跟我介紹的流程一致。希望今天的內容能夠對你有所幫助。

業務流程分析 未載入sso登錄模塊是怎么回事

業務流程分析未載入sso登錄模塊是怎么回事