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