作者：千鋒一一哥
前言
從本章節開始，一一哥 會給各位講解一個很常見也很重要的知識點，就是單點登入!現在的大型分布式項目，基本都會考慮實作單點登入，而且現在網上也有很多單點登入的實作方案、開源項目，但是針對單點登入的實作原理，講解的并不是很細。你可以參考其他開源案例項目，再結合本系列文章，就可以對單點登入有較為深入的認識。
如果你對單點登入是什麼也不知道，那就先看本文，了解單點登入的含義吧。
一. 單點登入
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直接傳回使用者請求的資源即可，整個流程如下圖所示：