單點登陸終極方案之 CAS 應用及原理

Cookie的單點登陸的實現方式很簡單，可是也問題頗多。例如：用戶名密碼不停傳送，增長了被盜號的可能。另外，不能跨域！

一、基於Cookie的單點登陸的回顧

基於Cookie的單點登陸核心原理：

將用戶名密碼加密以後存於Cookie中，以後訪問網站時在過濾器（filter）中校驗用戶權限，若是沒有權限則從Cookie中取出用戶名密碼進行登陸，讓用戶從某種意義上以爲只登陸了一次。

該方式缺點就是屢次傳送用戶名密碼，增長被盜風險，以及不能跨域。點擊這裏瞭解Java如何進行跨域。同時www.qiandu.com與mail.qiandu.com同時擁有登陸邏輯的代碼，若是涉及到修改操做，則須要修改兩處。

二、統一認證中心方案原理

在生活中咱們也有相似的相關生活經驗，例如你去食堂吃飯，食堂打飯的阿姨（www.qiandu.com）告訴你，不收現金。而且告訴你，你去門口找換票的（passport.com）換小票。因而你換完票以後，再去找食堂阿姨，食堂阿姨拿着你的票，問門口換票的，這個票是真的嗎？換票的說，是真的，因而給你打飯了。

基於上述生活中的場景，咱們將基於Cookie的單點登陸改良之後的方案以下：

通過分析，Cookie單點登陸認證太過於分散，每一個網站都持有一份登錄認證代碼。因而咱們將認證統一化，造成一個獨立的服務。當咱們須要登陸操做時，則重定向到統一認證中心http://passport.com。因而乎整個流程就如上圖所示：

第一步：用戶訪問www.qiandu.com。過濾器判斷用戶是否登陸，沒有登陸，則重定向（302）到網站http://passport.com。

第二步：重定向到passport.com，輸入用戶名密碼。passport.com將用戶登陸的信息記錄到服務器的session中。

第三步：passport.com給瀏覽器發送一個特殊的憑證，瀏覽器將憑證交給www.qiandu.com，www.qiandu.com則拿着瀏覽器交給他的憑證去passport.com驗證憑證是否有效，從而判斷用戶是否登陸成功

第四步：登陸成功，瀏覽器與網站之間進行正常的訪問。

三、Yelu大學研發的CAS(Central Authentication Server)

下面就以耶魯大學研發的CAS爲分析依據，分析其工做原理。首先看一下最上層的項目部署圖：

部署項目時須要部署一個獨立的認證中心（cas.qiandu.com），以及其餘N個用戶本身的web服務。

認證中心：也就是cas.qiandu.com，即cas-server。用來提供認證服務，由CAS框架提供，用戶只須要根據業務實現認證的邏輯便可。

用戶web項目：只須要在web.xml中配置幾個過濾器，用來保護資源，過濾器也是CAS框架提供了，即cas-client，基本不須要改動能夠直接使用。

四、CAS的詳細登陸流程

上圖是3個登陸場景，分別爲：第一次訪問www.qiandu.com、第二次訪問、以及登陸狀態下第一次訪問mail.qiandu.com。

下面就詳細說明上圖中每一個數字標號作了什麼，以及相關的請求內容，響應內容。

4.一、第一次訪問www.qiandu.com

標號1：用戶訪問http://www.qiandu.com，通過他的第一個過濾器（cas提供，在web.xml中配置）AuthenticationFilter。

過濾器全稱：org.jasig.cas.client.authentication.AuthenticationFilter

主要做用：判斷是否登陸，若是沒有登陸則重定向到認證中心。

標號2：www.qiandu.com發現用戶沒有登陸，則返回瀏覽器重定向地址。

首先能夠看到咱們請求www.qiandu.com，以後瀏覽器返回狀態碼302，而後讓瀏覽器重定向到cas.qiandu.com而且經過get的方式添加參數service，該參數目的是登陸成功以後會要重定向回來，所以須要該參數。而且你會發現，其實server的值就是編碼以後的咱們請求www.qiandu.com的地址。

標號3：瀏覽器接收到重定向以後發起重定向，請求cas.qiandu.com。

標號4：認證中心cas.qiandu.com接收到登陸請求，返回登錄頁面。

上圖就是標號3的請求，以及標號4的響應。請求的URL是標號2返回的URL。以後認證中心就展現登陸的頁面，等待用戶輸入用戶名密碼。

標號5：用戶在cas.qiandu.com的login頁面輸入用戶名密碼，提交。

標號6：服務器接收到用戶名密碼，則驗證是否有效，驗證邏輯可使用cas-server提供現成的，也能夠本身實現。

上圖就是標號5的請求，以及標號6的響應了。當cas.qiandu.com即csa-server認證經過以後，會返回給瀏覽器302，重定向的地址就是Referer中的service參數對應的值。後邊並經過get的方式挾帶了一個ticket令牌，這個ticket就是ST（數字3處）。同時會在Cookie中設置一個CASTGC，該cookie是網站cas.qiandu.com的cookie，只有訪問這個網站纔會攜帶這個cookie過去。

Cookie中的CASTGC：向cookie中添加該值的目的是當下次訪問cas.qiandu.com時，瀏覽器將Cookie中的TGC攜帶到服務器，服務器根據這個TGC，查找與之對應的TGT。從而判斷用戶是否登陸過了，是否須要展現登陸頁面。TGT與TGC的關係就像SESSION與Cookie中SESSIONID的關係。點擊這裏瞭解Java如何操做Cookie。

TGT：Ticket Granted Ticket（俗稱大令牌，或者說票根，他能夠簽發ST）

TGC：Ticket Granted Cookie（cookie中的value），存在Cookie中，根據他能夠找到TGT。

ST：Service Ticket （小令牌），是TGT生成的，默認是用一次就生效了。也就是上面數字3處的ticket值。

標號7：瀏覽器從cas.qiandu.com哪裏拿到ticket以後，就根據指示重定向到www.qiandu.com，請求的url就是上面返回的url。

標號8：www.qiandu.com在過濾器中會取到ticket的值，而後經過http方式調用cas.qiandu.com驗證該ticket是不是有效的。

標號9：cas.qiandu.com接收到ticket以後，驗證，驗證經過返回結果告訴www.qiandu.com該ticket有效。

標號10：www.qiandu.com接收到cas-server的返回，知道了用戶合法，展現相關資源到用戶瀏覽器上。

至此，第一次訪問的整個流程結束，其中標號8與標號9的環節是經過代碼調用的，並非瀏覽器發起，因此沒有截取到報文。

4.二、第二次訪問www.qiandu.com

上面以及訪問過一次了，當第二次訪問的時候發生了什麼呢？

標號11：用戶發起請求，訪問www.qiandu.com。會通過cas-client，也就是過濾器，由於第一次訪問成功以後www.qiandu.com中會在session中記錄用戶信息，所以這裏直接就經過了，不用驗證了。

標號12：用戶經過權限驗證，瀏覽器返回正常資源。

4.三、訪問mail.qiandu.com

標號13：用戶在www.qiandu.com正常上網，忽然想訪問mail.qiandu.com，因而發起訪問mail.qiandu.com的請求。

標號14：mail.qiandu.com接收到請求，發現第一次訪問，因而給他一個重定向的地址，讓他去找認證中心登陸。

上圖能夠看到，用戶請求mail.qiandu.com，而後返回給他一個網址，狀態302重定向，service參數就是回來的地址。

標號15：瀏覽器根據14返回的地址，發起重定向，由於以前訪問過一次了，所以此次會攜帶上次返回的Cookie：TGC到認證中心。

標號16：認證中心收到請求，發現TGC對應了一個TGT，因而用TGT簽發一個ST，而且返回給瀏覽器，讓他重定向到mail.qiandu.com

能夠發現請求的時候是攜帶Cookie：CASTGC的，響應的就是一個地址加上TGT簽發的ST也就是ticket。

標號17：瀏覽器根據16返回的網址發起重定向。

標號18：mail.qiandu.com獲取ticket去認證中心驗證是否有效。

標號19：認證成功，返回在mail.qiandu.com的session中設置登陸狀態，下次就直接登陸。

標號20：認證成功以後就反正用想要訪問的資源了。

五、總結

至此，CAS登陸的整個過程就完畢了，之後有時間總結下如何使用CAS，並運用到項目中。

更多精彩文章，關注公衆號【ToBeTopJavaer】，更有以下數萬元精品vip資源免費等你來拿！！！複製代碼