一、多系統的復雜性

web系統早已從久遠的單系統發展成為如今由多系統組成的應用群，面對如此眾多的系統，用戶難道要一個一個登錄、然后一個一個注銷嗎？就像下圖描述的這樣

　　web系統由單系統發展成多系統組成的應用群，復雜性應該由系統內部承擔，而不是用戶。無論web系統內部多么復雜，對用戶而言，都是一個統一的整體，也就是說，用戶訪問web系統的整個應用群與訪問單個系統一樣，登錄/注銷只要一次就夠了

雖然單系統的登錄解決方案很完美，但對于多系統應用群已經不再適用了，為什么呢？單系統登錄解決方案的核心是cookie，cookie攜帶會話id在瀏覽器與服務器之間維護會話狀態。但cookie是有限制的，這個限制就是cookie的域（通常對應網站的域名），瀏覽器發送http請求時會自動攜帶與該域匹配的cookie，而不是所有cookie

既然這樣，為什么不將web應用群中所有子系統的域名統一在一個頂級域名下，例如“*.baidu.com”，然后將它們的cookie域設置為“baidu.com”，這種做法理論上是可以的，甚至早期很多多系統登錄就采用這種同域名共享cookie的方式。然而，可行并不代表好，共享cookie的方式存在眾多局限。首先，應用群域名得統一；其次，應用群各系統使用的技術（至少是web服務器）要相同，不然cookie的key值（tomcat為JSESSIONID）不同，無法維持會話，共享cookie的方式是無法實現跨語言技術平臺登錄的，比如java、php、.net系統之間；第三，cookie本身不安全。因此，我們需要一種全新的登錄方式來實現多系統應用群的登錄，這就是單點登錄

二、什么是單點登錄（SSO）

單點登錄主要用于多系統集成，即在多個系統中，用戶只需要到一個中央服務器登錄一次即可訪問這些系統中的任何一個，無須多次登錄。單點登錄（Single Sign On），簡稱為 SSO，是目前比較流行的企業業務整合的解決方案之一。SSO的定義是在多個應用系統中，用戶只需要登錄一次就可以訪問所有相互信任的應用系統。

登錄

相比于單系統登錄，sso需要一個獨立的認證中心，只有認證中心能接受用戶的用戶名密碼等安全信息，其他系統不提供登錄入口，只接受認證中心的間接授權。間接授權通過令牌實現，sso認證中心驗證用戶的用戶名密碼沒問題，創建授權令牌，在接下來的跳轉過程中，授權令牌作為參數發送給各個子系統，子系統拿到令牌，即得到了授權，可以借此創建局部會話，局部會話登錄方式與單系統的登錄方式相同。這個過程，也就是單點登錄的原理，用下圖說明

下面對上圖簡要描述

用戶訪問系統1的受保護資源，系統1發現用戶未登錄，跳轉至sso認證中心，并將自己的地址作為參數

sso認證中心發現用戶未登錄，將用戶引導至登錄頁面

用戶輸入用戶名密碼提交登錄申請

sso認證中心校驗用戶信息，創建用戶與sso認證中心之間的會話，稱為全局會話，同時創建授權令牌

sso認證中心帶著令牌跳轉會最初的請求地址（系統1）

系統1拿到令牌，去sso認證中心校驗令牌是否有效

認證中心校驗令牌，返回有效，注冊系統1

系統1使用該令牌創建與用戶的會話，稱為局部會話，返回受保護資源

用戶訪問系統2的受保護資源

系統2發現用戶未登錄，跳轉至sso認證中心，并將自己的地址作為參數

sso認證中心發現用戶已登錄，跳轉回系統2的地址，并附上令牌

系統2拿到令牌，去sso認證中心校驗令牌是否有效

sso認證中心校驗令牌，返回有效，注冊系統2

系統2使用該令牌創建與用戶的局部會話，返回受保護資源

用戶登錄成功之后，會與sso認證中心及各個子系統建立會話，用戶與sso認證中心建立的會話稱為全局會話，用戶與各個子系統建立的會話稱為局部會話，局部會話建立之后，用戶訪問子系統受保護資源將不再通過sso認證中心，全局會話與局部會話有如下約束關系

局部會話存在，全局會話一定存在

全局會話存在，局部會話不一定存在

全局會話銷毀，局部會話必須銷毀

你可以通過博客園、百度、csdn、淘寶等網站的登錄過程加深對單點登錄的理解，注意觀察登錄過程中的跳轉url與參數

注銷

單點登錄自然也要單點注銷，在一個子系統中注銷，所有子系統的會話都將被銷毀，用下面的圖來說明

sso認證中心一直監聽全局會話的狀態，一旦全局會話銷毀，監聽器將通知所有注冊系統執行注銷操作,下面對上圖簡要說明

用戶向系統1發起注銷請求

系統1根據用戶與系統1建立的會話id拿到令牌，向sso認證中心發起注銷請求

sso認證中心校驗令牌有效，銷毀全局會話，同時取出所有用此令牌注冊的系統地址

sso認證中心向所有注冊系統發起注銷請求

各注冊系統接收sso認證中心的注銷請求，銷毀局部會話

sso認證中心引導用戶至登錄頁面

三、SSO部署圖

單點登錄涉及sso認證中心與眾子系統，子系統與sso認證中心需要通信以交換令牌、校驗令牌及發起注銷請求，因而子系統必須集成sso的客戶端，sso認證中心則是sso服務端，整個單點登錄過程實質是sso客戶端與服務端通信的過程，用下圖描述

sso認證中心與sso客戶端通信方式有多種，這里以簡單好用的httpClient為例，web service、rpc、restful api都可以

四、實現思路

sso采用客戶端/服務端架構，我們先看sso-client與sso-server要實現的功能（下面：sso認證中心=sso-server）

sso-client

攔截子系統未登錄用戶請求，跳轉至sso認證中心

接收并存儲sso認證中心發送的令牌

與sso-server通信，校驗令牌的有效性

建立局部會話

攔截用戶注銷請求，向sso認證中心發送注銷請求

接收sso認證中心發出的注銷請求，銷毀局部會話

sso-server

驗證用戶的登錄信息

創建全局會話

創建授權令牌

與sso-client通信發送令牌

校驗sso-client令牌有效性

系統注冊

接收sso-client注銷請求，注銷所有會話

五、SSO技術選型

• cas（單點登錄）

解決問題：多個系統只需登錄一次，無需重復登錄
原理：授權服務器，被授權客戶端

授權服務器（一個）保存了全局的一份session，客戶端（多個）各自保存自己的session

客戶端登錄時判斷自己的session是否已登錄，若未登錄，則（告訴瀏覽器）重定向到授權服務器（參數帶上自己的地址，用于回調）

授權服務器判斷全局的session是否已登錄，若未登錄則定向到登錄頁面，提示用戶登錄，登錄成功后，授權服務器重定向到客戶端（參數帶上ticket【一個憑證號】）

客戶端收到ticket后，請求服務器獲取用戶信息

服務器同意客戶端授權后，服務端保存用戶信息至全局session，客戶端將用戶保存至本地session

默認不支持http請求， 僅支持https

缺點：

cas單點登錄技術適用于傳統應用的場景比較多， 官方示例也是以javaWeb為準， 對微服務化應用，前后端分離應用，

支持性較差

• oauth2（第三方登錄授權）

解決問題：第三方系統訪問主系統資源，用戶無需將在主系統的賬號告知第三方，只需通過主系統的授權，第三方就可使用主系統的資源（

如：APP1需使用微信支付，微信支付會提示用戶是否授權，用戶授權后，APP1就可使用微信支付功能了）

原理：主系統，授權系統（給主系統授權用的，也可以跟主系統是同一個系統），第三方系統

第三方系統需要使用主系統的資源，第三方重定向到授權系統

根據不同的授權方式，授權系統提示用戶授權

用戶授權后，授權系統返回一個授權憑證（accessToken）給第三方系統【accessToken是有有效期的】

第三方使用accessToken訪問主系統資源【accessToken失效后，第三方需重新請求授權系統，以獲取新的accessToken】

OAUTH2中的角色：

Resource Server: 被授權訪問的資源

Authotization Server：OAUTH2認證授權中心

Resource owner : 資源擁有者

Client：使用API的客戶端(如Android 、IOS、web app)

工作流程如下：

• jwt (客戶端token)

Json web token (JWT), 是為了在網絡應用環境間傳遞聲明而執行的一種基于JSON的開放標準（(RFC 7519). 該token被設計為緊湊且安全的，特別適用于分布式站點的單點登錄（SSO）場景。JWT的聲明一般被用來在身份提供者和服務提供者間傳遞被認證的用戶身份信息，以便于從資源服務器獲取資源，也可以增加一些額外的其它業務邏輯所必須的聲明信息，該token也可直接被用于認證，也可被加密。

基于JWT認證協議，自己開發SSO服務和權限控制。 流程如下

六、安全控制框架

spring-security

spring-security 是spring家族的安全控制框架， 功能非常完善。 Spring Security是能夠為J2EE項目提供綜合性的安全訪問控制解決方案的安全框架。它依賴于Servlet過濾器。這些過濾器攔截進入請求，并且在應用程序處理該請求之前進行某些安全處理。

Spring Security對用戶請求的攔截過程如下:

shiro

Apache Shiro 是一個強大而靈活的開源安全框架，它干凈利落地處理身份認證，授權，企業會話管理和加密。

以下是你可以用 Apache Shiro 所做的事情：

• 1.驗證用戶來核實他們的身份
• 2.對用戶執行訪問控制，
  2.1判斷用戶是否被分配了一個確定的安全角色
  2.2判斷用戶是否被允許做某事
• 3.在任何環境下使用 Session API，即使沒有 Web 或 EJB 容器。
• 4.在身份驗證，訪問控制期間或在會話的生命周期，對事件作出反應。
• 5.聚集一個或多個用戶安全數據的數據源，并作為一個單一的復合用戶“視圖”。
• 6.啟用單點登錄（SSO）功能。 內置了jasig-cas
• 7.為沒有關聯到登錄的用戶啟用"Remember Me"服務

主流的技術搭配

• spring-security + oauth2
• spring-security + cas 功能較弱，對前后端分離的項目支持不是很好
• shiro + cas
• 比較
  

七、SSO落地實現技術

https://zhuanlan.zhihu.com/p/94622931
參考文章
參考文章

總結

以上是生活随笔為你收集整理的SSO模型及单点登录SSO技术选型的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。