作者：千鋒一一哥
前言
從本章節開始，一一哥 會給各位講解一個很常見也很重要的知識點，就是單點登錄!現在的大型分布式項目，基本都會考慮實現單點登錄，而且現在網上也有很多單點登錄的實現方案、開源項目，但是針對單點登錄的實現原理，講解的并不是很細。你可以參考其他開源案例項目，再結合本系列文章，就可以對單點登錄有較為深入的認識。
如果你對單點登錄是什么也不知道，那就先看本文，了解單點登錄的含義吧。
一. 單點登錄
1. 產生背景
很早的時候，一家公司里可能只有一個Server，后來慢慢的Server開始變多了，而每個Server都要進行注冊登錄，退出的時候又要一個個退出，用戶體驗很不好!
比如，我們想訪問百度系列，要登錄百度知道、百度新聞、百度貼吧、百度圖冊......百度旗下的每一個產品，我們都分別注冊一次賬號，都分別登陸一次，都分別退出登錄，這樣一個一個Server去操作，可能會讓人抓狂。
那么有沒有辦法，優化這樣的登錄體驗呢?比如：一個公司名下的任意服務只需一次注冊，登錄的時候只要一次登錄，退出的時候只要一次退出。如果可以實現這樣的需求，用戶體驗是不是會有很大的提升?那么該用什么實現呢?
2. 多系統中的登錄實現方案
想在多系統項目中實現登錄，目前有2種可行的實現方案：
· 同域名下共享Cookie
· 單點登錄
3. 共享Cookie方案的缺陷
雖然同域名下共享Cookie的方式，可以在一定程度上解決多系統中的登錄問題，但是該方案存在眾多局限性，如下：
· 應用的群域名必須統一;
· 應用群中各系統使用的Web技術(至少是Web服務器)要相同，否則cookie中key的名稱(Tomcat為JSESSIONID)不同，無法維持會話;
· 共享Cookie的方式無法實現跨語言技術平臺登錄，比如無法在Java、PHP、.Net等之間共享Cookie;
· Cookie本身也不安全。
4. SSO的概念
單點登錄(Single Sign On)，簡稱為SSO，是目前比較流行的企業業務整合的解決方案之一。SSO是指在多應用系統中，用戶只需要在某一個應用上登錄一次，就可以同時在所有相關又彼此獨立的系統中共享登錄態。
即只登錄一次，就能訪問所有相互信任的應用系統，在其他所有系統中也都得到了授權而無需再次登錄。另外用戶也只需要退出一次，即可退出所有其他可信的服務。所以SSO包括單點登錄與單點注銷兩部分。
5. SSO的優點
· 單點登錄降低了用戶的登錄成本;
· 統一了不同系統之間的賬號體系;
· 減少了各個系統在用戶設計上付出的精力。
6. 使用場景
一般每個單獨的系統都會有自己的安全體系和身份認證系統。在整合以前，進入每個系統都需要進行登錄，這樣的局面不僅給管理上帶來了很大的困難，在安全方面也埋下了重大的隱患。下面是一些著名的調查公司顯示的統計數據：
a. 用戶每天平均要花 16 分鐘在身份驗證任務上 - 資料來源： IDS
b. 頻繁的 IT 用戶平均有 21 個密碼 - 資料來源： NTA Monitor Password Survey
c. 49% 的人寫下了其密碼，而 67% 的人很少改變它們
d. 每 79 秒出現一起身份被竊事件 - 資料來源：National Small Business Travel Assoc
e. 全球欺騙損失每年約 12B - 資料來源：Comm Fraud Control Assoc
在使用“單點登錄”整合后，只需要登錄一次就可以進入多個系統，而不需要重新登錄。這不僅僅帶來了更好的用戶體驗，更重要的是降低了安全的風險和管理的消耗。請看下面的統計數據：
a. 提高 IT 效率：對于每 1000 個受管用戶，每用戶可節省$70K;
b. 幫助臺呼叫減少至少1/3，對于 10K 員工的公司，每年可以節省每用戶 $75，或者合計 $648K;
c. 生產力提高：每個新員工可節省 $1K，每個老員工可節省 $350 資料來源：Giga;
d. ROI 回報：7.5 到 13 個月 資料來源：Gartner
另外，使用 “單點登錄” 還是SOA微服務時代的需求之一。在面向服務的架構中，服務和服務之間，程序和程序之間的通訊大量存在，服務之間的安全認證是SOA應用的難點之一。
應此建立“單點登錄”的系統體系能夠大大簡化SOA的安全問題，提高服務之間的合作效率。
7. 單點登錄執行流程(重點)
在單點登錄系統中，需要定義一個獨立的認證中心，只有認證中心才能接受用戶的用戶名密碼等安全信息，而其他系統并不提供登錄入口，只接受認證中心的間接授權，間接授權通過令牌實現。
SSO認證中心驗證用戶的用戶名密碼時如果沒有問題，則創建授權令牌。在接下來的跳轉過程中，授權令牌會作為參數發送給各個子系統，子系統拿到授權令牌，即得到了授權，可以借此創建局部會話，局部會話的登錄方式與單系統的登錄方式相同。
這個過程，就是單點登錄的原理，我們用下圖來詳細說明。
根據上圖，我們可以梳理出單點登錄的請求執行流程(重點)：
a. 比如用戶訪問系統1的受保護資源，結果系統1發現用戶未登錄，會先跳轉到SSO認證中心，并將自己的地址作為參數，比如http://login.xxx.com/jump?target=http://系統1.com/xxx ;
b. SSO認證中心發現用戶未登錄，則將用戶引導到登錄頁面，并將系統1的地址作為參數帶過去;
c. 用戶輸入用戶名和密碼，向SSO認證中心提交登錄申請，并將系統1的地址作為參數帶過去;
d. SSO認證中心校驗用戶信息，校驗成功后，會創建一個用戶與SSO認證中心之間的會話，稱之為全局會話，同時創建一個授權令牌;
e. SSO認證中心帶著令牌跳轉回最初的請求地址(系統1);
f. 系統1拿到授權令牌后，接著去SSO認證中心校驗令牌是否有效，并將系統1的地址作為參數帶過去;
g. SSO認證中心先校驗令牌是否有效，正常則返回有效信息，并把系統1的信息注冊進SSO授權中心;
h. 系統1使用該授權令牌創建出與用戶的會話，稱為局部會話，然后給用戶返回受保護的資源;
i. 如果用戶繼續訪問系統2的受保護資源，也會與SSO授權中心進行交互授權;
j. 比如系統2發現用戶未登錄，則跳轉到SSO認證中心，并將自己的地址作為參數攜帶過去;
k. 如果SSO認證中心發現用戶已登錄，則跳轉回系統2的地址，并帶過去授權令牌;
l. 系統2拿到授權令牌，接著會去SSO認證中心校驗授權令牌是否有效;
m. SSO認證中心也會校驗授權令牌，并返回有效信息，把系統2的信息也注冊進行SSO授權中心;
n. 系統2使用該授權令牌創建一個與用戶的局部會話，返并回受保護的資源。
通過以上的SSO單點登錄執行流程，我們可以得知，用戶登錄成功之后，會與SSO認證中心及各個子系統之間建立會話。
用戶與SSO認證中心建立的會話稱為全局會話，用戶與各個子系統建立的會話稱為局部會話，局部會話建立之后，用戶訪問子系統受保護資源將不再通過SSO認證中心。全局會話與局部會話有如下約束關系：
· 局部會話存在，全局會話一定存在;
· 全局會話存在，局部會話不一定存在;
· 全局會話銷毀，局部會話必須銷毀。
單點登錄涉及到SSO認證中心與眾多子系統，各子系統與SSO認證中心之間需要通信以交換令牌、校驗令牌及發起注銷請求，因而各子系統必須集成SSO客戶端，SSO認證中心則是SSO服務端，整個單點登錄過程實質是SSO客戶端與服務端通信的過程。
8. 單獨注銷執行流程(重點)
在多應用系統中，我們既然實現了單點登錄，自然也要單點注銷，即在一個子系統中注銷后，所有子系統的會話都將被銷毀。我們用下圖來說明。
SSO認證中心會一直監聽全局會話的狀態，一旦發現全局會話被銷毀，監聽器將通知所有注冊系統執行注銷操作。
下面對上圖進行簡要說明：
· 比如用戶向系統1發起注銷請求;
· 系統1根據用戶與系統1建立的局部會話id拿到授權令牌，接著系統1向SSO認證中心發起注銷請求;
· SSO認證中心會先校驗授權令牌是否有效，然后銷毀全局會話，同時取出所有用此授權令牌注冊的系統地址;
· SSO認證中心向所有注冊系統發起注銷會話的請求;
· 各注冊系統接收到SSO認證中心的注銷請求，銷毀局部會話;
· 最后SSO認證中心會引導用戶到登錄頁面。
二. CAS單點登錄系統
1. CAS概念
前文我們給大家介紹過，如果在一個企業旗下的所有系統都使用同一的域名，其實實現單點登錄也挺簡單，我們只需要將Cookie的domain域設置為頂層域名，在服務器端進行會話共享即可。但是現實中并沒有這么理想的狀態，一般實現單點登錄的成本是比較高的，接下來我給大家介紹一個實現單點登錄的開源項目CAS，可以大大降低實現單點登錄的難度和開發成本。
CAS(Central Authentication Service)，即中心認證服務系統。在CAS系統中，分為CAS Server與CAS Client兩部分，CAS Server是單點登錄系統中負責驗證的服務端，CAS Client是CAS Server登錄態的客戶端。
2. CAS的核心概念(重點)
在CAS系統中有三個重要的術語：
· Ticket Grantfng Ticke(TGT)：這是用戶登錄后生成的票根，包含用戶的認證身份、有效期等信息，存儲于CAS Server中，類似于我們常見的服務器會話;
· Ticket Granted Cookie(TGC)：這是存儲在Cookie中的一段數據，類似于會話ID，用戶與CAS Server進行交互時，幫助用戶找到對應的TGT;
· Service Ticket(ST)：這是CAS Server使用TGT簽發的一張一次性票據，CAS Client 使用ST與CAS Server進行交互，以獲取用戶的驗證狀態。
3. CAS單點登錄執行步驟(重點)
CAS單點登錄的完整步驟如下：
(1)用戶先通過瀏覽器訪問CAS Client程序的某個頁面，例如http://cas.client.com/me;
(2)當CAS Client判斷用戶需要進行身份認證時，會攜帶service作為請求參數，并返回302狀態碼，指示瀏覽器重定向到CAS Server端，例如 http://cas.server.com/?service=http://cas. client.com/me.service，service是用戶的原訪問頁面;
(3)然后瀏覽器利用 service 重定向到CAS Server;
(4)CAS Server 獲取并校驗用戶cookie中攜帶的TGC，如果成功，則身份認證完成;否則將用戶重定向到CAS Server 提供的登錄頁，例如 http://cas.server.com/login?service=http://cas. client.com/me，由用戶輸入用戶名和密碼，完成身份認證;
(5)如果用戶已經登錄過系統，那么CAS Server可以直接獲取用戶的TGC，并根據TGC找到TGT。如果是首次登錄，則CAS Server 會首先生成TGT。每次驗證時，CAS Server 會根據 TGT簽發一個ST，并把ST拼接在service參數中，同時將相應的TGC設置到用戶的cookie中(域為CAS Server)，并返回302 狀態碼，指示瀏覽器重定向到 service，例如 http://cas.client.com/me?ticket=XXX;
(6)瀏覽器存儲TGC，并攜帶ST重定向到service;
(7)CAS Client取得ST(即請求參數中的ticket)后，會向CAS Server請求驗證該ST的有效性;
(8)若CAS Server驗證該ST是有效的，就告知CAS Client該用戶有效，并返回該用戶的信息。
CAS Client在獲取用戶信息時，可以使用session的形式管理用戶會話。后續的交互請求不再需要重定向到CAS Server，CAS Client直接返回用戶請求的資源即可，整個流程如下圖所示：
請各位把上面的單點登錄執行流程和CAS的核心概念牢固掌握，這些知識點有助于我們后文知識點的理解和掌握。敬請期待下文，如何搭建CAS服務端!
關注wx公眾號【Java架構棧】，領取更多Java學習資源
京公網安備 11010802030320號