多模塊web系統(tǒng)登錄設計
時間：2023-08-31 17:24:01 | 來源：網站運營
時間：2023-08-31 17:24:01 來源：網站運營
多模塊web系統(tǒng)登錄設計：前面在《單web應用系統(tǒng)登錄設計》中，都是從一個小型獨立的web系統(tǒng)角度做的登錄設計。要么是借助三方賬號系統(tǒng)的Oauth2.0能力，要么是作為一個子業(yè)務系統(tǒng)直接使用單點登錄的能力。
今天這一篇文章所要總結講述的，就是如何在一個多模塊web系統(tǒng)中，構建用戶登錄能力的技術方案。
多模塊web系統(tǒng)登錄設計
SSO單點登錄設計
認識SSO機制
對于對于一個大型的系統(tǒng)，往往具備兩個及以上的產品或子業(yè)務系統(tǒng)。將其中的用戶登錄邏輯抽離出來，統(tǒng)一在一個頁面進行一次頁面登錄，就能同時在各個子業(yè)務系統(tǒng)中達到登錄的效果。
打個比方，SSO 和我們去游樂園時購買的通票很像。
我們只要買一次通票，就可以玩所有游樂場內的設施，而不需要在過山車或者摩天輪那里重新買一次票。在這里，買票就相當于登錄認證，游樂場就相當于使用一套 SSO 的公司，各種游樂設施就相當于公司的各個子業(yè)務系統(tǒng)。
同域下的單點登錄
對于同域下的單點登錄，因為cookie可以同域共享，因此可以通過共享會話的形式快速構建該能力。 即用戶模塊完成用戶登錄后，在一級域名下設置cookie, 用戶在訪問時業(yè)務模塊時，攜帶該cookie，從共享session會話中獲取用戶登錄憑證。
但在大型的web應用中，sessoin會話在不同模塊中共享是不安全的。其他業(yè)務模塊往往通過服務互信的方式來獲取用戶憑證。和token鑒權或oauth鑒權模式一樣，仍然需要走到用戶模塊去進行鑒權。在SSO的術語中，提供鑒權的用戶模塊又可以叫CAS(Central Authentication Service)。下面，就梳理一下CAS的交互流程。
CAS （Central Authentication Service）
術語解釋
TGT：Ticket Grangting Ticket
TGT 是 CAS 為用戶簽發(fā)的登錄票據，擁有了 TGT，用戶就可以證明自己在 CAS 成功登錄過。TGT 封裝了 Cookie 值以及此 Cookie 值對應的用戶信息。當 HTTP 請求到來時，CAS 以此 Cookie 值（TGC）為 key 查詢緩存中有無 TGT ，如果有的話，則相信用戶已登錄過。
TGC：Ticket Granting Cookie
CAS Server 生成TGT放入自己的 Session 中，而 TGC 就是這個 Session 的唯一標識（SessionId），以 Cookie 形式放到瀏覽器端，是 CAS Server 用來明確用戶身份的憑證。
ST：Service Ticket
ST 是 CAS 為用戶簽發(fā)的訪問某一 service 的票據。用戶訪問 service 時，service 發(fā)現(xiàn)用戶沒有 ST，則要求用戶去 CAS 獲取 ST。用戶向 CAS 發(fā)出獲取 ST 的請求，CAS 發(fā)現(xiàn)用戶有 TGT，則簽發(fā)一個 ST，返回給用戶。用戶拿著 ST 去訪問 service，service 拿 ST 去 CAS 驗證，驗證通過后，允許用戶訪問資源。
CAS實現(xiàn)會話登錄的步驟：
- 用戶訪問系統(tǒng)1的受保護資源，系統(tǒng)1發(fā)現(xiàn)用戶未登錄，跳轉至sso認證中心，并將自己的地址作為參數(shù)
- sso認證中心發(fā)現(xiàn)用戶未登錄，將用戶引導至登錄頁面
- 用戶輸入用戶名密碼提交登錄申請
- sso認證中心校驗用戶信息，創(chuàng)建用戶與sso認證中心之間的會話，稱為全局會話，同時創(chuàng)建授權令牌。 （該步驟即創(chuàng)建了TGC（全局會話cookie）/TGT(全局會話session)/ST(授權令牌)
- sso認證中心帶著令牌跳轉會最初的請求地址（系統(tǒng)1)
- 系統(tǒng)1拿到令牌，去sso認證中心校驗令牌是否有效
- sso認證中心校驗令牌，返回有效，注冊系統(tǒng)1
- 系統(tǒng)1使用該令牌創(chuàng)建與用戶的會話，稱為局部會話，返回受保護資源
- 用戶訪問系統(tǒng)2的受保護資源
- 系統(tǒng)2發(fā)現(xiàn)用戶未登錄，跳轉至sso認證中心，并將自己的地址作為參數(shù)
- sso認證中心發(fā)現(xiàn)用戶已登錄，跳轉回系統(tǒng)2的地址，并附上令牌
- 系統(tǒng)2拿到令牌，去sso認證中心校驗令牌是否有效
- sso認證中心校驗令牌，返回有效，注冊系統(tǒng)2
- 系統(tǒng)2使用該令牌創(chuàng)建與用戶的局部會話，返回受保護資源
（這里的流程僅展示了子業(yè)務系統(tǒng)內訪問自己的受保護資源的方式。對于子業(yè)務系統(tǒng)內訪問其他業(yè)務系統(tǒng)的受保護資源，其實現(xiàn)原理及方案則需要引入Oauth2.0機制，這里不做細究。）
用戶登錄成功之后，會與sso認證中心及各個子系統(tǒng)建立會話，用戶與sso認證中心建立的會話稱為全局會話，用戶與各個子系統(tǒng)建立的會話稱為局部會話，局部會話建立之后，用戶訪問子系統(tǒng)受保護資源將不再通過sso認證中心，全局會話與局部會話有如下約束關系： 1. 局部會話存在，全局會話一定存在 2. 全局會話存在，局部會話不一定存在 3. 全局會話銷毀，局部會話必須銷毀
第1點和第2點，因為局部會話都是由子業(yè)務系統(tǒng)向認證中心主動發(fā)起鑒權，所以說天然滿足。但對于第3點，則需要一個通知機制，從認證中心向子業(yè)務系統(tǒng)發(fā)出。
CAS實現(xiàn)會話注銷的步驟
1. 用戶向系統(tǒng)1發(fā)起注銷請求
2. 系統(tǒng)1根據用戶與系統(tǒng)1建立的會話id拿到令牌，向sso認證中心發(fā)起注銷請求
3. sso認證中心校驗令牌有效，銷毀全局會話，同時取出所有用此令牌注冊的系統(tǒng)地址
4. sso認證中心向所有注冊系統(tǒng)發(fā)起注銷請求
5. 各注冊系統(tǒng)接收sso認證中心的注銷請求，銷毀局部會話
6. sso認證中心引導用戶至登錄頁面
因為這個通知機制，需要在認證中心額外存儲ST與注冊系統(tǒng)的映射關系，并通過異步消息隊列完成通知。對應的業(yè)務系統(tǒng)也得維護這個局部會話的時效性。
CAS的技術能力
CAS采用客戶端/服務端架構
CAS Client:
1. 攔截子系統(tǒng)未登錄用戶請求，跳轉至sso認證中心
2. 接收并存儲sso認證中心發(fā)送的令牌
3. 與CAS Server通信，校驗令牌的有效性
4. 建立局部會話
5. 攔截用戶注銷請求，向sso認證中心發(fā)送注銷請求
6. 接收sso認證中心發(fā)出的注銷請求，銷毀局部會話
CAS Server:
1. 驗證用戶的登錄信息
2. 創(chuàng)建全局會話
3. 創(chuàng)建授權令牌
4. 與CAS Client通信發(fā)送令牌
5. 校驗CAS Client令牌有效性
6. 系統(tǒng)注冊
7. 接收CAS Client注銷請求，注銷所有會話
統(tǒng)一網關+授權中心
對于一個使用微服務架構的大型系統(tǒng)來說，相比于獨立一個CAS服務，構建一個API網關可能是一個更優(yōu)雅的解決方案。將用戶的認證鑒權統(tǒng)一到網關模塊進行統(tǒng)一處理，
鑒權邏輯描述
- 當客戶端第一次請求服務時，網關發(fā)現(xiàn)未攜帶token，向授權中心請求授權
- 客戶端完成對用戶進行信息認證（登錄）
- 認證通過，將用戶信息進行簽名加密形成token，返回給客戶端
- 客戶端每次請求，都攜帶認證的token
- 發(fā)送給服務端的請求，首先經過網關，網關向授權中心發(fā)起鑒權，鑒權通過則放行。
該方案之于SSO，就猶如token鑒權之于session會話管理。該方案相較于CAS模式，有一個天然的優(yōu)勢，即同時支持多端的登錄鑒權。
單設備登錄設計
對于一些敏感應用，需要有一定的風控措施，例如說僅允許單設備登錄。對應于web端，相當于僅允許一個登錄憑證或sessionId有效，你如果換了瀏覽器或異地登錄，系統(tǒng)則需要將以前的會話踢出，并警示風險。
在CAS模式下，這需要SSO認證中心內緩存的userId與ST的映射關系再添加上一些其他信息。例如將userId和全局sessionId一起作為key來檢索ST, 則可以保證換了瀏覽器或主機的情況下可以識別到重復登錄了，如果將urserId和ip一起作為key來檢索ST，則可以保證同一時刻異地登錄可以得到檢測。
同理，網關token模式下，可以將userId和token/ip一起做key來檢索用戶登錄憑證。而在App側，單設備登錄可以控制得更加精細。
當然，如果收集更多用戶登錄的環(huán)境信息或歷史行為信息，可以更精準地對用戶做風險控制。
在線咨詢
