作者：Readiay
https://blog.csdn.net/Readiay/article/details/52856510
Cookie的單點登錄的實作方式很簡單，但是也問題頗多，例如：用戶名密碼不停傳送，增加了被盜號的可能，另外，不能跨域！
1、基于Cookie的單點登錄的回顧
基于Cookie的單點登錄核心原理：
將用戶名密碼加密之后存于Cookie中，之后訪問網站時在過濾器（filter）中校驗用戶權限，如果沒有權限則從Cookie中取出用戶名密碼進行登錄，讓用戶從某種意義上覺得只登錄了一次，
該方式缺點就是多次傳送用戶名密碼，增加被盜風險，以及不能跨域，點擊這里了解Java如何進行跨域，同時www.qiandu.com與mail.qiandu.com同時擁有登錄邏輯的代碼，如果涉及到修改操作，則需要修改兩處，
2、統一認證中心方案原理
在生活中我們也有類似的相關生活經驗，例如你去食堂吃飯，食堂打飯的阿姨（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驗證憑證是否有效，從而判斷用戶是否登錄成功
第四步：登錄成功，瀏覽器與網站之間進行正常的訪問，
3、Yelu大學研發的CAS(Central Authentication Server)
下面就以耶魯大學研發的CAS為分析依據，分析其作業原理，首先看一下最上層的專案部署圖：
部署專案時需要部署一個獨立的認證中心（cas.qiandu.com），以及其他N個用戶自己的web服務，
認證中心：也就是cas.qiandu.com，即cas-server，用來提供認證服務，由CAS框架提供，用戶只需要根據業務實作認證的邏輯即可，
用戶web專案：只需要在web.xml中配置幾個過濾器，用來保護資源，過濾器也是CAS框架提供了，即cas-client，基本不需要改動可以直接使用，
4、CAS的詳細登錄流程
上圖是3個登錄場景，分別為：第一次訪問www.qiandu.com、第二次訪問、以及登錄狀態下第一次訪問mail.qiandu.com，
下面就詳細說明上圖中每個數字標號做了什么，以及相關的請求內容，回應內容，
4.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的關系，點擊這里了解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.2、第二次訪問www.qiandu.com
上面以及訪問過一次了，當第二次訪問的時候發生了什么呢？
標號11：用戶發起請求，訪問www.qiandu.com，會經過cas-client，也就是過濾器，因為第一次訪問成功之后www.qiandu.com中會在session中記錄用戶資訊，因此這里直接就通過了，不用驗證了，
標號12：用戶通過權限驗證，瀏覽器回傳正常資源，
4.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：認證成功之后就反正用想要訪問的資源了，
5、總結
至此，CAS登錄的整個程序就完畢了，以后有時間總結下如何使用CAS，并運用到專案中，
推薦去我的博客閱讀更多：
1.Java JVM、集合、多執行緒、新特性系列教程
2.Spring MVC、Spring Boot、Spring Cloud 系列教程
3.Maven、Git、Eclipse、Intellij IDEA 系列工具教程
4.Java、后端、架構、阿里巴巴等大廠最新面試題
覺得不錯，別忘了點贊+轉發哦！
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/186225.html
標籤：Java