cas單點登錄源碼

A. 終於搞明白了，CAS單點登錄原理解析！！

真的如老話所說，「沒有笨的人，只有懶得人」。前段時間時間需要和其他項目做cas集成，於是乎在網上找了幾篇教程看了一下，好了，很簡單，學會了，開搞（自以為研究明白）。集成完事了，登錄成功了，自以為這就過去了。然而，沒過幾天就出bug了，這下慘了，當初沒有好好學出了問題都不知道咋解決。無奈，只得靜下心來好好學習一番（當初太懶付出的代價）。原理其實很簡單的，只要耐下心來好好研究終會搞懂的。

先看下圖

那麼是如何驗證用戶是否登錄過呢？

如果session中包含「 const_cas_assertion 」屬性，說明已經登錄，跳過此過濾器執行配置的其他過濾器；

如果ticket參數不為空（可能是登陸後跳轉回來的），跳過此過濾器，執行TicketValidationFilter 驗證ticket；

如果前兩個條件都不滿足，重定向到cas服務端，返回登錄頁面進行登錄操作。

Cookie中的CASTGC：向cookie中添加該值的目的是當下次訪問 www.cas.server.com 時，瀏覽器將Cookie中的TGC攜帶到伺服器，伺服器根據這個TGC，查找與之對應的TGT。從而判斷用戶是否登錄過了，是否需要展示登錄頁面。TGT與TGC的關系就像SESSION與Cookie中SESSIONID的關系。

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

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

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

為了加深理解，也為了以後作參考，整理記錄。另外，還要說一句，不要偷懶，多動手多動腦！

B. 單點登錄cas 高手請進spring報錯……

你的是耶魯的那個cas嗎，那個客戶端與某些spring版本有沖突，我當初用spring1.2.6沒問題，這個客戶端還必須在能解析dns的機器上運行不然報連接超時，因為源碼裡面加密那段代碼有訪問耶魯的網站

C. CAS搭建單點登錄Web端

①前端vue項目判斷如果有token,則說明用戶已登錄，可以訪問客戶端A的服務。否則未登陸，未登陸有兩種狀態：在單點登錄服務端已經登錄和未在單點登錄服務端登陸

    判斷如果有ticket，則說明已在單點登錄服務端登錄。調用/cas/client/validateLogin介面驗證該ticket是否有效。轉②

    判斷如果無ticket,則說明未在單點登錄服務端登錄。則定向到單點登錄服務端。轉③

②/cas/client/validateLogin介面方法，發起http請求到單點登錄服務端進行ticket驗證，如果驗證通過，則登錄成功。單點登錄客戶端A生成token返回給前端，之後前端通過攜帶token訪問客戶端A的服務。

③單點登錄服務端返回登錄表單，用戶輸入用戶名密碼確定登錄後，單點登錄服務端調用用戶信息驗證端/auth/user/login介面，傳遞用戶名密碼參數，將驗證委託給用戶信息驗證端

④登錄成功驗證通過後，攜帶ticket返回瀏覽器，重定向地址如下:

http://localhost:8000/?ticket=ST-6-NqvtyjRhezstXiyyzNNN-C-DiTw-DESKTOP-CVVQ0QK

接入用戶信息驗證端參考

D. 怎麼導入cas單點登錄源碼進行編輯

SSO將一個企業內部所有域中的用戶登錄和用戶帳號管理集中到一起，SSO的好處顯而易見： 減少用戶在不同系統中登錄耗費的時間，減少用戶登錄出錯的可能性 實現安全的同時避免了處理和保存多套系統用戶的認證信息 減少了系統管理員增加、刪除用戶和...

E. CAS 中央認證服務 實現 單點登錄（SSO）

CAS—認證原理

單點登錄系統(SSO)之CAS(中央認證服務)

CAS中央認證系統

F. 【單點登錄】CAS協議

CAS協議是專門為CAS開發的一種簡單而強大的基於票據的協議。

CAS涉及到一個或多個客戶端與一個服務端，客戶端嵌入CASified應用程序(稱為「CAS服務」)，而CAS伺服器是一個獨立組件:

1.CAS伺服器負責對用戶進行身份驗證並授予對應用程序的訪問權

2.CAS客戶端保護CAS應用程序，並從CAS伺服器檢索被授予用戶的標識。

關鍵概念：

1.存儲在CASTGC cookie中的 TGT (票據授予票據)表示用戶的一個SSO session。

2. ST (服務票證)作為url中的GET參數傳輸，表示由CAS伺服器為特定用戶授予認證應用程序的訪問許可權。

WEB流程：

1.用戶訪問目標應用程序，通過瀏覽器發送GET請求到目標應用

2.目標應用檢測到用戶未認證，則轉發請求到CAS服務端，帶上查詢參數service，值為目標應用地址。

3.CAS服務端檢測用戶發現沒有SSO session 則返回CAS登錄頁面。

4.用戶在CAS登錄頁面填寫登錄表單，提交進行認證。

5.認證成功後CAS服務端創建SSO session,並創建TGT票據到Cookie中 （Set-Cookie:CASTGC=TGT-xxxxxx），並重定向到目標應用程序帶上查詢參數ticket=ST-xxxxx。

6.目標應用發送請求向CAS伺服器驗證ST票據，驗證成功後目標應用創建用戶訪問session,並把sessionID放入cookie中。

7.用戶訪問目標應用通過sessionID獲取到session,登陸成功。

8.用戶訪問其他CAS客戶端應用，其他CAS客戶端重定向請求到CAS伺服器，同步驟2。

9.CAS伺服器檢測到用戶TGT這個cookie,獲取到SSO session，直接認證成功，並重定向到目標應用程序帶上查詢參數ticket=ST-xxxxx。

10.同步驟6，7，成功登陸其他CAS客戶端應用。

G. CAS-5.3單點登錄/退出客戶端搭建(Springboot)

使用Springboot搭建cas客戶端，主要是配置四個過濾器和一個監聽器。

用於過濾不需要登錄的用戶，需要實現UrlPatternMatcherStrategy 介面，在matches 函數里添加不需要用戶登錄的鏈接。

按照同樣的方法實現客戶端系統2。
啟動cas伺服器端和兩個客戶端。輸入 http://springbootcasclient.com:8001/ ，則跳轉到登錄界面

單點退出，需要下面三個步驟:1、添加過濾器類，過濾掉不需要登錄的url；2、添加退出跳轉的控制器；3、修改服務端application.properties ，加cas.logout.followServiceRedirects=true，讓客戶端可以自己制定退出的路徑，否則會走默認退出路徑。

過濾器類需要實現UrlPatternMatcherStrategy介面，然後配置到springboot中，請參考 單點登錄 的 創建過濾器類 和 配置過濾器到springboot 。

退出的方式有兩種，一種是走默認的路徑，另一種是走自定義的返迴路徑。請參考 單點登錄 的 用戶退出控制器 。

將上面的內容添加到applicaiton.properties, 這樣就可以允許客戶端定製自己的退出路徑了。

http協議配置：cas 5.3.x默認客戶端不支持http協議, 如果不進行配置，則會出現「未認證授權的服務」錯誤。

要配置兼容http協議，需要在HTTPSandIMAPS-10000001.json文件中添加http。

H. CAS 單點登錄原理解析

CAS是耶魯大學發起的一個開源單點登錄項目，也是用的最為廣泛的開源項目。對於學習SSO有非常好的參考價值

單點登錄（Single Sign On），簡稱為 SSO。多用於多系統共存的環境下，用戶在一處登錄後，就不用在其他系統中登錄，最簡單的單點登入實現可以完全基於 cookie ，通過往瀏覽器寫帶有登入信息的token來達到多點登入的目的，有興趣的可以自己動手實現一個

先盜個圖 ：

從結構上看，分成了三部分：CAS Client，CAS Server，瀏覽器

CAS Client 與受保護的客戶端應用部署在一起，以 Filter 方式保護 Web 應用的受保護資源，過濾從客戶端過來的每一個Web請求

下面我將分為兩部分（用戶第一次登錄驗證和之後的登錄驗證）詳細解析其登入原理

以上是第一次驗證時基本流程

跨域的關鍵在於瀏覽器端的Cookie: TGC ，因為這個Cookie是設置在 SSO Server 端的，也就保證了統一票據和 Client 端域名無關。

cas 單點登錄核心就是 單個cookie ， N個session

在該協議中，所有與 CAS Server 的交互均採用 SSL 協議，以確保 ST 和 TGC 的安全性。

I. CAS單點登錄原理分析(一)

一，業務分析

在分布式系統架構中，假設把上述的三個子系統部署在三個不同的伺服器上。前提是用戶登錄之後才能訪問這些子系統。那麼使用傳統方式，可能會存在這樣的問題：

1.當訪問用戶中心，需要用戶登錄帳號

2.當訪問購物車，還需要用戶登錄帳號

3.當訪問商品結算，又一次需要用戶登錄帳號

訪問每一個子系統都需要用戶登錄帳號，這樣的體驗對於用戶來說是極差。而使用單點登錄就可以很好地解決上述的問題。

二，單點登錄

單點登錄（Single Sign On），簡稱為 SSO，是目前比較流行的企業業務整合的解決方案之一。SSO 的定義是在多個應用系統中，用戶只需要登錄一次就可以訪問所有相互信任的應用系統。

我們目前的系統存在諸多子系統，而這些子系統是分別部署在不同的伺服器中，那麼使用傳統方式的 session 是無法解決的，我們需要使用相關的單點登錄技術來解決。

第一步 ：用戶訪問應用系統1。過濾器判斷用戶是否登錄，沒有登錄，則重定向（302）到認證系統去進行認證操作。

第二步 ：重定向到認證系統，顯示登錄界面，用戶輸入用戶名密碼。認證系統將用戶登錄的信息記錄到伺服器的session中。

第三步 ：認證系統給瀏覽器發送一個特殊的憑證ticket，瀏覽器將憑證交給應用系統1，應用系統1則拿著瀏覽器交給他的憑證ticket去認證系統驗證憑證ticket是否有效。憑證ticket若是有效，將用戶信息保存到應用系統1的session中一份，並告知應用系統1，用戶通過認證。

第四步 ：用戶通過認證，瀏覽器與網站之間進行正常的訪問。

第五步 ：當用戶再次訪問應用系統1，由於應用系統1的session中有用戶信息，所以就不用經過認證系統認證，就可以直接訪問應用系統1了。

第六步 ：當用戶再去訪問其他應用系統時，瀏覽器會帶著憑證ticket過去，其他應用系統到認證系統驗證憑證，憑證ticket若是有效，將用戶信息保存到其他應用系統的session中一份，並告知其他應用系統，用戶通過認證。

第七步 ：用戶通過認證，瀏覽器與網站之間進行正常的訪問。

第八步 ：當用戶再次訪問其他應用系統，由於其他應用系統的session中有用戶信息，所以就不用經過認證系統認證，就可以直接訪問其他應用系統了。

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

1.什麼是CAS？

CAS 是 Yale 大學發起的一個開源項目，旨在為 Web 應用系統提供一種可靠的單點登錄方法，CAS 在 2004 年 12 月正式成為 JA-SIG 的一個項目。CAS 具有以下特點：

【1】開源的企業級單點登錄解決方案。

【2】CAS Server 為需要獨立部署的 Web 應用。這個CAS框架已經提供

【3】CAS Client 支持非常多的客戶端(這里指單點登錄系統中的各個 Web 應用)，包括Java, .Net, PHP, Perl, Apache, uPortal, Ruby 等。

從結構上看，CAS 包含兩個部分： CAS Server 和 CAS Client。CAS Server 需要獨立部署，主要負責對用戶的認證工作；CAS Client 負責處理對客戶端受保護資源的訪問請求，需要登錄時，重定向到 CAS Server。下圖是 CAS 最基本的協議過程：

2.CAS的詳細登錄流程

該圖主要描述

1.第一次訪問http://shopping.xiaogui.com

2.在登錄狀態下第二次訪問http://shopping.xiaogui.com

3.在登錄狀態下第一次訪問http://pay.xiaogui.com

下面對圖中序號代表的操作進行說明

當用戶第一次訪問http://shopping.xiaogui.com

序號1: 用戶請求http://shopping.xiaogui.com，會經過AuthenticationFilter認證過濾器(在cas client 的web.xml中配置)

主要作用：判斷是否登錄，如果沒有登錄則重定向到認證中心。

大概知道這個就行，CAS的具體實現會在以後的博客中寫道

序號2:  AuthenticationFilter發現用戶沒有登錄，則返回瀏覽器重定向地址。

重定向的地址就是認證伺服器CAS Server的地址，後面的參數是我們請求的客戶端地址，這個參數目的就是為了認證成功以後，根據這個參數的地址重定向回請求的客戶端

序號3:  瀏覽器根據響應回來的重定向地址，向cas.xiaogui.com認證系統發出請求

序號4:  認證系統cas.xiaogui.com接收請求，響應登陸頁面

序號5: ：用戶登陸頁面輸入用戶名密碼，提交請求

序號6: ：CAS Server 認證伺服器接收用戶名和密碼，就行驗證，驗證邏輯CAS Server 已經實現，並響應給瀏覽器信息

這里的用戶名，密碼不需要關心，後續會講到

圖中1，2部分表示序號5 輸入的用戶名，密碼，以及發出的請求。當認證伺服器驗證通過之後，根據請求參數service的值，進行重定向，其實就是回到了請求的客戶端，同時會攜帶一個ticket令牌參數。同時會在Cookie中設置一個TGC，該cookie是網站認證系統cas.xiaogui.com的cookie，只有訪問這個網站才會攜帶這個cookie過去。

*****注意：這個攜帶TGC的Cookie是實現CAS單點登錄的關鍵所在！

Cookie中的TGC：向cookie中添加該值的目的是當下次訪問cas.xiaogui.com認證系統時，瀏覽器將Cookie中的TGC攜帶到伺服器，伺服器根據這個TGC，查找與之對應的TGT。從而判斷用戶是否登錄過了，是否需要展示登錄頁面。TGT與TGC的關系就像SESSION與Cookie中SESSIONID的關系。

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

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

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

序號7:  客戶端拿到請求中的ticket信息，也就是圖中1的位置

然後經過一個ticket過濾器，去認證系統CAS Server判斷ticket是否有效

這個過濾器的主要工作就是校驗客戶端傳過來的ticket是否有效

CAS Client 客戶端  shopping.xiaogui.com  中web.xml的配置

序號8:  向CAS Server認證系統發出驗證ticket的請求，也就是圖中2的位置，然後執行ticket驗證

序號9:  通過校驗之後，把用戶信息保存到客戶端的session中，並把客戶端的SessionID設置在Cookie中，同時告知客戶端ticket有效。當用戶再次訪問該客戶端，就可以根據Cookie 中的SessionID找到客戶端的Session，獲取用戶信息，就不用再次進行驗證了。也就是圖中響應給瀏覽器的部分。

序號10:  shopping.xiaogui.com客戶端接收到cas-server的返回，知道了用戶已經登錄，ticket有效，告知瀏覽器可以進行訪問。

至此，用戶第一次訪問流程結束。

當用戶第二次訪問http://shopping.xiaogui.com

序號11: 當用戶第二次訪問，仍然會經過AuthenticationFilter過濾器，但與第一次訪問不同的是此時客戶端session中已經存在用戶的信息，瀏覽器中的Cookie會根據SessionID找到Session，獲取用戶信息，所以不需要進行驗證，可以直接訪問。

序號12:  客戶端告知瀏覽器可以進行訪問。

當用戶第一次訪問http://pay.xiaogui.com

序號13:   用戶向pay.xiaogui.com  CAS Client客戶端發出請求

序號14:  ：pay.xiaogui.com接收到請求，發現第一次訪問，於是給他一個重定向的地址，讓他去找認證中心登錄。

序號15: 瀏覽器根據上面響應的地址，發起重定向，因為之前訪問過一次了，因此這次會攜帶上次返回的Cookie：TGC到認證中心。

序號16:  認證中心收到請求，發現TGC對應了一個TGT，於是用TGT簽發一個ticket，並且返回給瀏覽器，讓他重定向到pay.xiaogui.comCAS Client客戶端。

序號17: 根據上面響應回來的地址，進行重定向到pay.xiaogui.comCAS Client客戶端

序號18:  pay.xiaogui.comCAS Client客戶端帶著ticket去認證中心驗證是否有效。

序號19:  認證成功，把用戶信息保存到客戶端的session中，並把客戶端的SessionID設置在Cookie中。當用戶下次訪問pay.xiaogui.comCAS Client客戶端，直接登錄，無需驗證。

序號20:  告知瀏覽器可以進行訪問

CAS單點登錄的原理分析大致就是上述的這些，至於CAS單點登錄的具體實現，將在下篇博客中寫道。

J. CAS搭建單點登錄rest認證-APP端接入方案

     <!-- restful -->

        <dependency>

              <groupId>org.apereo.cas</groupId>

              <artifactId>cas-server-support-rest</artifactId>

              <version>${cas.version}</version>

     </dependency>

     # ticket過期設置

     cas.ticket.st.numberOfUses=1

     cas.ticket.st.timeToKillInSeconds=60

註：http://localhost:9527/auth/cas/client/validateLogin為被保護後台封裝的介面，該介面主要有兩個功能：①調用https://cas.ananops.com:8443/cas/p3/serviceValidate向單點登錄服務端驗證該ST的真實性。②ST確認真實後，生成ACCESS-TOKEN以及登錄用戶信息並返回給APP端，用戶訪問被保護後台的服務。

postman測試https介面需要配置：