作者：千鋒一一哥

　　前言

　　從本章節(jié)開(kāi)始，一一哥 會(huì)給各位講解一個(gè)很常見(jiàn)也很重要的知識(shí)點(diǎn)，就是單點(diǎn)登錄!現(xiàn)在的大型分布式項(xiàng)目，基本都會(huì)考慮實(shí)現(xiàn)單點(diǎn)登錄，而且現(xiàn)在網(wǎng)上也有很多單點(diǎn)登錄的實(shí)現(xiàn)方案、開(kāi)源項(xiàng)目，但是針對(duì)單點(diǎn)登錄的實(shí)現(xiàn)原理，講解的并不是很細(xì)。你可以參考其他開(kāi)源案例項(xiàng)目，再結(jié)合本系列文章，就可以對(duì)單點(diǎn)登錄有較為深入的認(rèn)識(shí)。

　　如果你對(duì)單點(diǎn)登錄是什么也不知道，那就先看本文，了解單點(diǎn)登錄的含義吧。

　　一. 單點(diǎn)登錄

　　1. 產(chǎn)生背景

　　很早的時(shí)候，一家公司里可能只有一個(gè)Server，后來(lái)慢慢的Server開(kāi)始變多了，而每個(gè)Server都要進(jìn)行注冊(cè)登錄，退出的時(shí)候又要一個(gè)個(gè)退出，用戶體驗(yàn)很不好!

　　比如，我們想訪問(wèn)百度系列，要登錄百度知道、百度新聞、百度貼吧、百度圖冊(cè)......百度旗下的每一個(gè)產(chǎn)品，我們都分別注冊(cè)一次賬號(hào)，都分別登陸一次，都分別退出登錄，這樣一個(gè)一個(gè)Server去操作，可能會(huì)讓人抓狂。

　　那么有沒(méi)有辦法，優(yōu)化這樣的登錄體驗(yàn)?zāi)?比如：一個(gè)公司名下的任意服務(wù)只需一次注冊(cè)，登錄的時(shí)候只要一次登錄，退出的時(shí)候只要一次退出。如果可以實(shí)現(xiàn)這樣的需求，用戶體驗(yàn)是不是會(huì)有很大的提升?那么該用什么實(shí)現(xiàn)呢?

　　2. 多系統(tǒng)中的登錄實(shí)現(xiàn)方案

　　想在多系統(tǒng)項(xiàng)目中實(shí)現(xiàn)登錄，目前有2種可行的實(shí)現(xiàn)方案：

　　· 同域名下共享Cookie

　　· 單點(diǎn)登錄

　　3. 共享Cookie方案的缺陷

　　雖然同域名下共享Cookie的方式，可以在一定程度上解決多系統(tǒng)中的登錄問(wèn)題，但是該方案存在眾多局限性，如下：

　　· 應(yīng)用的群域名必須統(tǒng)一;

　　· 應(yīng)用群中各系統(tǒng)使用的Web技術(shù)(至少是Web服務(wù)器)要相同，否則cookie中key的名稱(Tomcat為JSESSIONID)不同，無(wú)法維持會(huì)話;

　　· 共享Cookie的方式無(wú)法實(shí)現(xiàn)跨語(yǔ)言技術(shù)平臺(tái)登錄，比如無(wú)法在Java、PHP、.Net等之間共享Cookie;

　　· Cookie本身也不安全。

　　4. SSO的概念

　　單點(diǎn)登錄(Single Sign On)，簡(jiǎn)稱為SSO，是目前比較流行的企業(yè)業(yè)務(wù)整合的解決方案之一。SSO是指在多應(yīng)用系統(tǒng)中，用戶只需要在某一個(gè)應(yīng)用上登錄一次，就可以同時(shí)在所有相關(guān)又彼此獨(dú)立的系統(tǒng)中共享登錄態(tài)。

　　即只登錄一次，就能訪問(wèn)所有相互信任的應(yīng)用系統(tǒng)，在其他所有系統(tǒng)中也都得到了授權(quán)而無(wú)需再次登錄。另外用戶也只需要退出一次，即可退出所有其他可信的服務(wù)。所以SSO包括單點(diǎn)登錄與單點(diǎn)注銷兩部分。

　　5. SSO的優(yōu)點(diǎn)

　　· 單點(diǎn)登錄降低了用戶的登錄成本;

　　· 統(tǒng)一了不同系統(tǒng)之間的賬號(hào)體系;

　　· 減少了各個(gè)系統(tǒng)在用戶設(shè)計(jì)上付出的精力。

　　6. 使用場(chǎng)景

　　一般每個(gè)單獨(dú)的系統(tǒng)都會(huì)有自己的安全體系和身份認(rèn)證系統(tǒng)。在整合以前，進(jìn)入每個(gè)系統(tǒng)都需要進(jìn)行登錄，這樣的局面不僅給管理上帶來(lái)了很大的困難，在安全方面也埋下了重大的隱患。下面是一些著名的調(diào)查公司顯示的統(tǒng)計(jì)數(shù)據(jù)：

　　a. 用戶每天平均要花 16 分鐘在身份驗(yàn)證任務(wù)上 - 資料來(lái)源： IDS

　　b. 頻繁的 IT 用戶平均有 21 個(gè)密碼 - 資料來(lái)源： NTA Monitor Password Survey

　　c. 49% 的人寫下了其密碼，而 67% 的人很少改變它們

　　d. 每 79 秒出現(xiàn)一起身份被竊事件 - 資料來(lái)源：National Small Business Travel Assoc

　　e. 全球欺騙損失每年約 12B - 資料來(lái)源：Comm Fraud Control Assoc

　　在使用“單點(diǎn)登錄”整合后，只需要登錄一次就可以進(jìn)入多個(gè)系統(tǒng)，而不需要重新登錄。這不僅僅帶來(lái)了更好的用戶體驗(yàn)，更重要的是降低了安全的風(fēng)險(xiǎn)和管理的消耗。請(qǐng)看下面的統(tǒng)計(jì)數(shù)據(jù)：

　　a. 提高 IT 效率：對(duì)于每 1000 個(gè)受管用戶，每用戶可節(jié)省$70K;

　　b. 幫助臺(tái)呼叫減少至少1/3，對(duì)于 10K 員工的公司，每年可以節(jié)省每用戶 $75，或者合計(jì) $648K;

　　c. 生產(chǎn)力提高：每個(gè)新員工可節(jié)省 $1K，每個(gè)老員工可節(jié)省 $350 資料來(lái)源：Giga;

　　d. ROI 回報(bào)：7.5 到 13 個(gè)月 資料來(lái)源：Gartner

　　另外，使用 “單點(diǎn)登錄” 還是SOA微服務(wù)時(shí)代的需求之一。在面向服務(wù)的架構(gòu)中，服務(wù)和服務(wù)之間，程序和程序之間的通訊大量存在，服務(wù)之間的安全認(rèn)證是SOA應(yīng)用的難點(diǎn)之一。

　　應(yīng)此建立“單點(diǎn)登錄”的系統(tǒng)體系能夠大大簡(jiǎn)化SOA的安全問(wèn)題，提高服務(wù)之間的合作效率。

　　7. 單點(diǎn)登錄執(zhí)行流程(重點(diǎn))

　　在單點(diǎn)登錄系統(tǒng)中，需要定義一個(gè)獨(dú)立的認(rèn)證中心，只有認(rèn)證中心才能接受用戶的用戶名密碼等安全信息，而其他系統(tǒng)并不提供登錄入口，只接受認(rèn)證中心的間接授權(quán)，間接授權(quán)通過(guò)令牌實(shí)現(xiàn)。

　　SSO認(rèn)證中心驗(yàn)證用戶的用戶名密碼時(shí)如果沒(méi)有問(wèn)題，則創(chuàng)建授權(quán)令牌。在接下來(lái)的跳轉(zhuǎn)過(guò)程中，授權(quán)令牌會(huì)作為參數(shù)發(fā)送給各個(gè)子系統(tǒng)，子系統(tǒng)拿到授權(quán)令牌，即得到了授權(quán)，可以借此創(chuàng)建局部會(huì)話，局部會(huì)話的登錄方式與單系統(tǒng)的登錄方式相同。

　　這個(gè)過(guò)程，就是單點(diǎn)登錄的原理，我們用下圖來(lái)詳細(xì)說(shuō)明。

　　根據(jù)上圖，我們可以梳理出單點(diǎn)登錄的請(qǐng)求執(zhí)行流程(重點(diǎn))：

　　a. 比如用戶訪問(wèn)系統(tǒng)1的受保護(hù)資源，結(jié)果系統(tǒng)1發(fā)現(xiàn)用戶未登錄，會(huì)先跳轉(zhuǎn)到SSO認(rèn)證中心，并將自己的地址作為參數(shù)，比如http://login.xxx.com/jump?target=http://系統(tǒng)1.com/xxx ;

　　b. SSO認(rèn)證中心發(fā)現(xiàn)用戶未登錄，則將用戶引導(dǎo)到登錄頁(yè)面，并將系統(tǒng)1的地址作為參數(shù)帶過(guò)去;

　　c. 用戶輸入用戶名和密碼，向SSO認(rèn)證中心提交登錄申請(qǐng)，并將系統(tǒng)1的地址作為參數(shù)帶過(guò)去;

　　d. SSO認(rèn)證中心校驗(yàn)用戶信息，校驗(yàn)成功后，會(huì)創(chuàng)建一個(gè)用戶與SSO認(rèn)證中心之間的會(huì)話，稱之為全局會(huì)話，同時(shí)創(chuàng)建一個(gè)授權(quán)令牌;

　　e. SSO認(rèn)證中心帶著令牌跳轉(zhuǎn)回最初的請(qǐng)求地址(系統(tǒng)1);

　　f. 系統(tǒng)1拿到授權(quán)令牌后，接著去SSO認(rèn)證中心校驗(yàn)令牌是否有效，并將系統(tǒng)1的地址作為參數(shù)帶過(guò)去;

　　g. SSO認(rèn)證中心先校驗(yàn)令牌是否有效，正常則返回有效信息，并把系統(tǒng)1的信息注冊(cè)進(jìn)SSO授權(quán)中心;

　　h. 系統(tǒng)1使用該授權(quán)令牌創(chuàng)建出與用戶的會(huì)話，稱為局部會(huì)話，然后給用戶返回受保護(hù)的資源;

　　i. 如果用戶繼續(xù)訪問(wèn)系統(tǒng)2的受保護(hù)資源，也會(huì)與SSO授權(quán)中心進(jìn)行交互授權(quán);

　　j. 比如系統(tǒng)2發(fā)現(xiàn)用戶未登錄，則跳轉(zhuǎn)到SSO認(rèn)證中心，并將自己的地址作為參數(shù)攜帶過(guò)去;

　　k. 如果SSO認(rèn)證中心發(fā)現(xiàn)用戶已登錄，則跳轉(zhuǎn)回系統(tǒng)2的地址，并帶過(guò)去授權(quán)令牌;

　　l. 系統(tǒng)2拿到授權(quán)令牌，接著會(huì)去SSO認(rèn)證中心校驗(yàn)授權(quán)令牌是否有效;

　　m. SSO認(rèn)證中心也會(huì)校驗(yàn)授權(quán)令牌，并返回有效信息，把系統(tǒng)2的信息也注冊(cè)進(jìn)行SSO授權(quán)中心;

　　n. 系統(tǒng)2使用該授權(quán)令牌創(chuàng)建一個(gè)與用戶的局部會(huì)話，返并回受保護(hù)的資源。

　　通過(guò)以上的SSO單點(diǎn)登錄執(zhí)行流程，我們可以得知，用戶登錄成功之后，會(huì)與SSO認(rèn)證中心及各個(gè)子系統(tǒng)之間建立會(huì)話。

　　用戶與SSO認(rèn)證中心建立的會(huì)話稱為全局會(huì)話，用戶與各個(gè)子系統(tǒng)建立的會(huì)話稱為局部會(huì)話，局部會(huì)話建立之后，用戶訪問(wèn)子系統(tǒng)受保護(hù)資源將不再通過(guò)SSO認(rèn)證中心。全局會(huì)話與局部會(huì)話有如下約束關(guān)系：

　　· 局部會(huì)話存在，全局會(huì)話一定存在;

　　· 全局會(huì)話存在，局部會(huì)話不一定存在;

　　· 全局會(huì)話銷毀，局部會(huì)話必須銷毀。

　　單點(diǎn)登錄涉及到SSO認(rèn)證中心與眾多子系統(tǒng)，各子系統(tǒng)與SSO認(rèn)證中心之間需要通信以交換令牌、校驗(yàn)令牌及發(fā)起注銷請(qǐng)求，因而各子系統(tǒng)必須集成SSO客戶端，SSO認(rèn)證中心則是SSO服務(wù)端，整個(gè)單點(diǎn)登錄過(guò)程實(shí)質(zhì)是SSO客戶端與服務(wù)端通信的過(guò)程。

　　8. 單獨(dú)注銷執(zhí)行流程(重點(diǎn))

　　在多應(yīng)用系統(tǒng)中，我們既然實(shí)現(xiàn)了單點(diǎn)登錄，自然也要單點(diǎn)注銷，即在一個(gè)子系統(tǒng)中注銷后，所有子系統(tǒng)的會(huì)話都將被銷毀。我們用下圖來(lái)說(shuō)明。

　　SSO認(rèn)證中心會(huì)一直監(jiān)聽(tīng)全局會(huì)話的狀態(tài)，一旦發(fā)現(xiàn)全局會(huì)話被銷毀，監(jiān)聽(tīng)器將通知所有注冊(cè)系統(tǒng)執(zhí)行注銷操作。

　　下面對(duì)上圖進(jìn)行簡(jiǎn)要說(shuō)明：

　　· 比如用戶向系統(tǒng)1發(fā)起注銷請(qǐng)求;

　　· 系統(tǒng)1根據(jù)用戶與系統(tǒng)1建立的局部會(huì)話id拿到授權(quán)令牌，接著系統(tǒng)1向SSO認(rèn)證中心發(fā)起注銷請(qǐng)求;

　　· SSO認(rèn)證中心會(huì)先校驗(yàn)授權(quán)令牌是否有效，然后銷毀全局會(huì)話，同時(shí)取出所有用此授權(quán)令牌注冊(cè)的系統(tǒng)地址;

　　· SSO認(rèn)證中心向所有注冊(cè)系統(tǒng)發(fā)起注銷會(huì)話的請(qǐng)求;

　　· 各注冊(cè)系統(tǒng)接收到SSO認(rèn)證中心的注銷請(qǐng)求，銷毀局部會(huì)話;

　　· 最后SSO認(rèn)證中心會(huì)引導(dǎo)用戶到登錄頁(yè)面。

　　二. CAS單點(diǎn)登錄系統(tǒng)

　　1. CAS概念

　　前文我們給大家介紹過(guò)，如果在一個(gè)企業(yè)旗下的所有系統(tǒng)都使用同一的域名，其實(shí)實(shí)現(xiàn)單點(diǎn)登錄也挺簡(jiǎn)單，我們只需要將Cookie的domain域設(shè)置為頂層域名，在服務(wù)器端進(jìn)行會(huì)話共享即可。但是現(xiàn)實(shí)中并沒(méi)有這么理想的狀態(tài)，一般實(shí)現(xiàn)單點(diǎn)登錄的成本是比較高的，接下來(lái)我給大家介紹一個(gè)實(shí)現(xiàn)單點(diǎn)登錄的開(kāi)源項(xiàng)目CAS，可以大大降低實(shí)現(xiàn)單點(diǎn)登錄的難度和開(kāi)發(fā)成本。

　　CAS(Central Authentication Service)，即中心認(rèn)證服務(wù)系統(tǒng)。在CAS系統(tǒng)中，分為CAS Server與CAS Client兩部分，CAS Server是單點(diǎn)登錄系統(tǒng)中負(fù)責(zé)驗(yàn)證的服務(wù)端，CAS Client是CAS Server登錄態(tài)的客戶端。

　　2. CAS的核心概念(重點(diǎn))

　　在CAS系統(tǒng)中有三個(gè)重要的術(shù)語(yǔ)：

　　· Ticket Grantfng Ticke(TGT)：這是用戶登錄后生成的票根，包含用戶的認(rèn)證身份、有效期等信息，存儲(chǔ)于CAS Server中，類似于我們常見(jiàn)的服務(wù)器會(huì)話;

　　· Ticket Granted Cookie(TGC)：這是存儲(chǔ)在Cookie中的一段數(shù)據(jù)，類似于會(huì)話ID，用戶與CAS Server進(jìn)行交互時(shí)，幫助用戶找到對(duì)應(yīng)的TGT;

　　· Service Ticket(ST)：這是CAS Server使用TGT簽發(fā)的一張一次性票據(jù)，CAS Client 使用ST與CAS Server進(jìn)行交互，以獲取用戶的驗(yàn)證狀態(tài)。

　　3. CAS單點(diǎn)登錄執(zhí)行步驟(重點(diǎn))

　　CAS單點(diǎn)登錄的完整步驟如下：

　　(1)用戶先通過(guò)瀏覽器訪問(wèn)CAS Client程序的某個(gè)頁(yè)面，例如http://cas.client.com/me;

　　(2)當(dāng)CAS Client判斷用戶需要進(jìn)行身份認(rèn)證時(shí)，會(huì)攜帶service作為請(qǐng)求參數(shù)，并返回302狀態(tài)碼，指示瀏覽器重定向到CAS Server端，例如 http://cas.server.com/?service=http://cas. client.com/me.service，service是用戶的原訪問(wèn)頁(yè)面;

　　(3)然后瀏覽器利用 service 重定向到CAS Server;

　　(4)CAS Server 獲取并校驗(yàn)用戶cookie中攜帶的TGC，如果成功，則身份認(rèn)證完成;否則將用戶重定向到CAS Server 提供的登錄頁(yè)，例如 http://cas.server.com/login?service=http://cas. client.com/me，由用戶輸入用戶名和密碼，完成身份認(rèn)證;

　　(5)如果用戶已經(jīng)登錄過(guò)系統(tǒng)，那么CAS Server可以直接獲取用戶的TGC，并根據(jù)TGC找到TGT。如果是首次登錄，則CAS Server 會(huì)首先生成TGT。每次驗(yàn)證時(shí)，CAS Server 會(huì)根據(jù) TGT簽發(fā)一個(gè)ST，并把ST拼接在service參數(shù)中，同時(shí)將相應(yīng)的TGC設(shè)置到用戶的cookie中(域?yàn)镃AS Server)，并返回302 狀態(tài)碼，指示瀏覽器重定向到 service，例如 http://cas.client.com/me?ticket=XXX;

　　(6)瀏覽器存儲(chǔ)TGC，并攜帶ST重定向到service;

　　(7)CAS Client取得ST(即請(qǐng)求參數(shù)中的ticket)后，會(huì)向CAS Server請(qǐng)求驗(yàn)證該ST的有效性;

　　(8)若CAS Server驗(yàn)證該ST是有效的，就告知CAS Client該用戶有效，并返回該用戶的信息。

　　CAS Client在獲取用戶信息時(shí)，可以使用session的形式管理用戶會(huì)話。后續(xù)的交互請(qǐng)求不再需要重定向到CAS Server，CAS Client直接返回用戶請(qǐng)求的資源即可，整個(gè)流程如下圖所示：

　　請(qǐng)各位把上面的單點(diǎn)登錄執(zhí)行流程和CAS的核心概念牢固掌握，這些知識(shí)點(diǎn)有助于我們后文知識(shí)點(diǎn)的理解和掌握。敬請(qǐng)期待下文，如何搭建CAS服務(wù)端!

關(guān)注wx公眾號(hào)【Java架構(gòu)棧】，領(lǐng)取更多Java學(xué)習(xí)資源