原文：https://blog.csdn.net/cruise_h/article/details/51013597

https://blog.csdn.net/weixin_42813765/article/details/82315305

https://www.cnblogs.com/codestory/p/5512104.html

Spring Security與CAS結合使用的意義

web應用中一個登陸過程，其實就是完成認證與授權。

所謂認證，就是當用戶試圖進入系統，而系統發現使用者沒有登陸，就調轉到登陸頁面。

所謂授權,指使用者認證通過之後對該使用者賦許可權，即該使用者能夠訪問這個系統的哪些功能（即該使用者能夠訪問這個系統的哪些url地址及按鈕）

Cas它的功能就是進行使用者名稱密碼認證。如果spring security與cas整合，就相當於spring security自身的登入認證功能轉移到cas框架上，然後spring security進行認證之後的授權。

CAS原理和協議

基礎模式

基礎模式SSO訪問流程主要有以下步驟：

1. 訪問服務：SSO客戶端傳送請求訪問應用系統提供的服務資源。

2. 定向認證：SSO客戶端會重定向使用者請求到SSO伺服器。

3. 使用者認證：使用者身份認證。

4. 發放票據：SSO伺服器會產生一個隨機的Service Ticket。

5. 驗證票據：SSO伺服器驗證票據Service Ticket的合法性，驗證通過後，允許客戶端訪問服務。

6. 傳輸使用者資訊：SSO伺服器驗證票據通過後，傳輸使用者認證結果資訊給客戶端。

如上圖：CAS Client 與受保護的客戶端應用部署在一起，以Filter方式保護Web應用的受保護資源，過濾從客戶端過來的每一個Web請求，同時，CAS Client 會分析HTTP請求中是否包含請求Service Ticket( ST上圖中的Ticket) ，如果沒有，則說明該使用者是沒有經過認證的；於是CAS Client 會重定向使用者請求到 CAS Server（Step 2），並傳遞Service（要訪問的目的資源地址）。 Step 3是使用者認證過程，如果使用者提供了正確的Credentials， CAS Server隨機產生一個相當長度、唯一、不可偽造的Service Ticket，並快取以待將來驗證，並且重定向使用者到Service 所在地址（附帶剛才產生的Service Ticket ）, 併為客戶端瀏覽器設定一個Ticket Granted Cookie（TGC）

在該協議中，所有與CAS Server的互動均採用SSL協議，以確保ST和TGC的安全性。協議工作過程中會有兩次重定向的過程。但是 CAS Client與CAS Server之間進行Ticket驗證的過程對於使用者是透明的（使用HttpsURLConnection）。

各服務首次訪問：若使用者沒有登入過執行以下圖全部流程。若以在其他服務中登入則執行到下圖第二步

同服務第二次訪問（因為之前已建立session,所以不會再去cas server）

CAS 如何實現 SSO

當用戶訪問另一個應用的服務再次被重定向到CAS Server的時候，CAS Server會主動獲到這個TGC cookie，然後做下面的事情：

1) 如果User持有TGC且其還沒失效，那麼就走基礎協議圖的Step4，達到了 SSO 的效果；

2) 如果TGC失效，那麼使用者還是要重新認證 (走基礎協議圖的Step3)。

 輔助說明

CAS的SSO實現方式可簡化理解為：1個Cookie和N個Session。CAS Server建立cookie，在所有應用認證時使用，各應用通過建立各自的Session來標識使用者是否已登入。

使用者在一個應用驗證通過後，以後使用者在同一瀏覽器裡訪問此應用時，客戶端應用中的過濾器會在session裡讀取到使用者資訊，所以就不會去CAS Server認證。如果在此瀏覽器裡訪問別的web應用時，客戶端應用中的過濾器在session裡讀取不到使用者資訊，就會去CAS Server的login介面認證，但這時CAS Server會讀取到瀏覽器傳來的cookie（TGC），所以CAS Server不會要求使用者去登入頁面登入，只是會根據service引數生成一個Ticket，然後再和web應用做一個驗證ticket的互動而已。

Session共享

可以通過Nginx+SpringSession實現Session共享，這樣既可以同步Session資訊，又能使其他應用不用再做首次認證

https://www.cnblogs.com/codestory/p/5512104.html

Cas登入過期時間

1、修改Cas Server的CASTGC過期時間
修改Cas Server下cas/WEB-INF/spring-configuration/ticketExpirationPolicies.xml（CASTGC的過期時間，單位為秒）

<bean id="grantingTicketExpirationPolicy" class="org.jasig.cas.ticket.support.TicketGrantingTicketExpirationPolicy"
     p:maxTimeToLiveInSeconds="28800"
     p:timeToKillInSeconds="1800"/>

2、修改Cas Client的Session過期時間
向Cas Client下WEB-INF/web.xml新增以下程式碼（Session過期時間，單位為分鐘）：

     <session-config>
        <session-timeout>30</session-timeout>
    </session-config>

 CAS代理模式

該模式形式為使用者訪問App1，App1又依賴於App2來獲取一些資訊，如：User -->App1 -->App2 。

這種情況下，假設App2也是需要對User進行身份驗證才能訪問，那麼，為了不影響使用者體驗（過多的重定向導致User的IE視窗不停地閃動)，CAS引入了一種Proxy認證機制，即CAS Client可以代理使用者去訪問其它Web應用。

代理的前提是需要CAS Client擁有使用者的身份資訊(類似憑據)。之前我們提到的TGC是使用者持有對自己身份資訊的一種憑據，這裡的PGT就是CAS Client端持有的對使用者身份資訊的一種憑據。憑藉TGC，User可以免去輸入密碼以獲取訪問其它服務的Service Ticket，所以，這裡憑藉PGT，Web應用可以代理使用者去實現後端的認證，而無需前端使用者的參與。