cas整體流程

SSO單點登入訪問流程主要有以下步驟：
1. 訪問服務：SSO客戶端傳送請求訪問應用系統提供的服務資源。

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

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

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

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

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

詳細的登入流程

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

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

1、第一次訪問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的關係。

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的環節是通過程式碼呼叫的，並不是瀏覽器發起，所以沒有擷取到報文。

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

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

標號11：使用者發起請求，訪問www.qiandu.com。會經過cas-client，也就是過濾器，因為第一次訪問成功之後www.qiandu.com中會在session中記錄使用者資訊，因此這裡直接就通過了，不用驗證了。

標號12：使用者通過許可權驗證，瀏覽器返回正常資源。

3、訪問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：認證成功之後就反正用想要訪問的資源了。

轉載：https://www.cnblogs.com/Eleven-Liu/p/10336181.html