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