長沙Java培訓系列教程之實現CAS單點登入上篇

       從本篇文章開始 一一哥 會給各位講解 系列教程一個很常見也很重要的知識點，就是單點登入！現在的大型分散式專案，基本都會考慮實現單點登入，而且現在網上也有很多單點登入的實現方案、開源專案，但是針對單點登入的實現原理，講解的並不是很細。你可以參考其他開源案例專案，再結合本系列文章，就可以對單點登入有較為深入的認識。

       如果你對單點登入是什麼也不知道，那就先看本文，瞭解單點登入的含義吧。

       一. 單點登入

       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. 使用場景

       一般每個單獨的系統都會有自己的安全體系和身份認證系統。在整合以前，進入每個系統都需要進行登入，這樣的局面不僅給管理上帶來了很大的困難，在安全方面也埋下了重大的隱患。下面是一些著名的調查公司顯示的統計資料：

       使用者每天平均要花 16 分鐘在身份驗證任務上 - 資料來源： IDS頻繁的 IT 使用者平均有 21 個密碼 - 資料來源： NTA Monitor Password Survey49% 的人寫下了其密碼，而 67% 的人很少改變它們每 79 秒出現一起身份被竊事件 - 資料來源：National Small Business Travel Assoc全球欺騙損失每年約 12B - 資料來源：Comm Fraud Control Assoc

       在使用“單點登入”整合後，只需要登入一次就可以進入多個系統，而不需要重新登入。這不僅僅帶來了更好的使用者體驗，更重要的是降低了安全的風險和管理的消耗。請看下面的統計資料：

       提高 IT 效率：對於每 1000 個受管使用者，每使用者可節省$70K；幫助臺呼叫減少至少1/3，對於 10K 員工的公司，每年可以節省每使用者 $75，或者合計 $648K；生產力提高：每個新員工可節省 $1K，每個老員工可節省 $350 資料來源：Giga；ROI 回報：7.5 到 13 個月 資料來源：Gartner

       另外，使用 “單點登入” 還是SOA微服務時代的需求之一。在面向服務的架構中，服務和服務之間，程式和程式之間的通訊大量存在，服務之間的安全認證是SOA應用的難點之一。

       應此建立“單點登入”的系統體系能夠大大簡化SOA的安全問題，提高服務之間的合作效率。

       7. 單點登入執行流程(重點)

       在單點登入系統中，需要定義一個獨立的認證中心，只有認證中心才能接受使用者的使用者名稱密碼等安全資訊，而其他系統並不提供登入入口，只接受認證中心的間接授權，間接授權透過令牌實現。

       SSO認證中心驗證使用者的使用者名稱密碼時如果沒有問題，則建立授權令牌。在接下來的跳轉過程中，授權令牌會作為引數傳送給各個子系統，子系統拿到授權令牌，即得到了授權，可以藉此建立區域性會話，區域性會話的登入方式與單系統的登入方式相同。

       這個過程，就是單點登入的原理，我們用下圖來詳細說明。

       根據上圖，我們可以梳理出單點登入的請求執行流程(重點)：

       比如使用者訪問系統1的受保護資源，結果系統1發現使用者未登入，會先跳轉到SSO認證中心，並將自己的地址作為引數，比如系統1.com/xxx ；SSO認證中心發現使用者未登入，則將使用者引導到登入頁面，並將系統1的地址作為引數帶過去；使用者輸入使用者名稱和密碼，向SSO認證中心提交登入申請，並將系統1的地址作為引數帶過去；SSO認證中心校驗使用者資訊，校驗成功後，會建立一個使用者與SSO認證中心之間的會話，稱之為全域性會話，同時建立一個授權令牌；SSO認證中心帶著令牌跳轉回最初的請求地址(系統1)；系統1拿到授權令牌後，接著去SSO認證中心校驗令牌是否有效，並將系統1的地址作為引數帶過去；SSO認證中心先校驗令牌是否有效，正常則返回有效資訊，並把系統1的資訊註冊進SSO授權中心；系統1使用該授權令牌建立出與使用者的會話，稱為區域性會話，然後給使用者返回受保護的資源；如果使用者繼續訪問系統2的受保護資源，也會與SSO授權中心進行互動授權；比如系統2發現使用者未登入，則跳轉到SSO認證中心，並將自己的地址作為引數攜帶過去；如果SSO認證中心發現使用者已登入，則跳轉回系統2的地址，並帶過去授權令牌；系統2拿到授權令牌，接著會去SSO認證中心校驗授權令牌是否有效；SSO認證中心也會校驗授權令牌，並返回有效資訊，把系統2的資訊也註冊進行SSO授權中心；系統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簽發的一張一次性PIAO據，CAS Client 使用ST與CAS Server進行互動，以獲取使用者的驗證狀態。

       3. CAS單點登入執行步驟 (重點)

       CAS單點登入的完整步驟如下：

       （1）使用者先透過瀏覽器訪問CAS Client程式的某個頁面，例如；

       （2）當CAS Client判斷使用者需要進行身份認證時，會攜帶service作為請求引數，並返回302狀態碼，指示瀏覽器重定向到CAS Server端，例如  client.com/me.service，service是使用者的原訪問頁面；

       （3）然後瀏覽器利用 service 重定向到CAS Server；

       （4）CAS Server 獲取並校驗使用者cookie中攜帶的TGC，如果成功，則身份認證完成；否則將使用者重定向到CAS Server 提供的登入頁，例如  client.com/me，由使用者輸入使用者名稱和密碼，完成身份認證；

       （5）如果使用者已經登入過系統，那麼CAS Server可以直接獲取使用者的TGC，並根據TGC找到TGT。如果是首次登入，則CAS Server 會首先生成TGT。每次驗證時，CAS Server 會根據 TGT簽發一個ST，並把ST拼接在service引數中，同時將相應的TGC設定到使用者的cookie中(域為CAS Server)，並返回302 狀態碼，指示瀏覽器重定向到 service，例如 ?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服務端！