一、不落俗套的開始

1、背景介紹

單點登入：Single Sign On,簡稱SSO，SSO使得在多個應用系統中，使用者只需要登入一次就可以訪問所有相互信任的應用系統。

CAS框架：CAS（Central Authentication Service）是實現SSO單點登入的框架。

2、盜一張學習CAS絕大多都看過的圖以及執行部分分析

注：已分不清原創，此處就不給出地址了。

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

CAS Client 與受保護的客戶端應用部署在一起，以Filter方式保護 Web 應用的受保護資源，過濾從客戶端過來的每一個 Web 
請求，同時， CAS Client會分析HTTP 請求中是否包請求 Service Ticket( 上圖中的 Ticket) 
，如果沒有，則說明該使用者是沒有經過認證的，於是，CAS Client會重定向使用者請求到CAS Server（ Step 2 ）。 Step 
3是使用者認證過程，如果使用者提供了正確的Credentials， CAS Server 會產生一個隨機的 Service Ticket 
，然後，快取該 Ticket ，並且重定向使用者到CAS Client（附帶剛才產生的Service Ticket）， Service 
Ticket 是不可以偽造的，最後， Step 5 和 Step6是 CAS Client 和 CAS 
Server之間完成了一個對使用者的身份核實，用Ticket查到 Username ，因為 Ticket是 CAS Server 
產生的，因此，所以 CAS Server 的判斷是毋庸置疑的。

該協議完成了一個很簡單的任務，所有與CAS的互動均採用SSL協議，確保ST和TGC的安全性。協議工作過程會有2此重定向過程，但是CAS 
Client與CAS Server之間進行ticket驗證的過程對於使用者是透明的。

總結一下，如下：

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

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

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

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

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

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

二、在雲裡霧裡進一步搜尋、探究

先給出此部分內容出處： 《SSO CAS單點系列》之 實現一個SSO認證伺服器是這樣的，以下標紅部分為自己的疑問。

1、登入資訊傳遞

 
使用者首次登入時流程如下：

1)、使用者瀏覽器訪問系統A需登入受限資源，此時進行登入檢查，發現未登入，然後進行獲取票據操作，發現沒有票據。

2)、系統A發現該請求需要登入，將請求重定向到認證中心，獲取全域性票據操作，沒有，進行登入。

3)、認證中心呈現登入頁面，使用者登入，登入成功後，認證中心重定向請求到系統A，並附上認證通過令牌，此時認證中心同時生成了全域性票據。

4)、此時再次進行登入檢查，發現未登入，然後再次獲取票據操作，此時可以獲得票據(令牌)，系統A與認證中心通訊，驗證令牌有效,證明使用者已登入。

5)、系統A將受限資源返給使用者。

 
已登入使用者首次訪問應用群中系統B時：

1)、瀏覽器訪問另一應用B需登入受限資源，此時進行登入檢查，發現未登入，然後進行獲取票據操作，發現沒有票據。

2)、系統B發現該請求需要登入，將請求重定向到認證中心，獲取全域性票據操作，獲取全域性票據，可以獲得，認證中心發現已經登入。

3)、認證中心發放臨時票據(令牌)，並攜帶該令牌重定向到系統B。

4)、此時再次進行登入檢查，發現未登入，然後再次獲取票據操作，此時可以獲得票據(令牌)，系統B與認證中心通訊，驗證令牌有效,證明使用者已登入。

5)、系統B將受限資源返回給客戶端。

2、登入狀態判斷

使用者到認證中心登入後，使用者和認證中心之間建立起了會話，我們把這個會話稱為全域性會話。當使用者後續訪問系統應用時，我們不可能每次應用請求都到認證中心去判定是否登入，這樣效率非常低下，這也是單Web應用不需要考慮的。

我們可以在系統應用和使用者瀏覽器之間建立起區域性會話，區域性會話保持了客戶端與該系統應用的登入狀態，區域性會話依附於全域性會話存在，全域性會話消失，區域性會話必須消失。

使用者訪問應用時，首先判斷區域性會話是否存在，如存在，即認為是登入狀態，無需再到認證中心去判斷。如不存在，就重定向到認證中心判斷全域性會話是否存在，如存在，按1提到的方式通知該應用，該應用與客戶端就建立起它們之間區域性會話，下次請求該應用，就不去認證中心驗證了。

3、登出

使用者在一個系統登出了，訪問其它子系統，也應該是登出狀態。要想做到這一點，應用除結束本地區域性會話外，還應該通知認證中心該使用者登出。

認證中心接到登出通知，即可結束全域性會話，同時需要通知所有已建立區域性會話的子系統，將它們的區域性會話銷燬。這樣，使用者訪問其它應用時，都顯示已登出狀態。

整個登出流程如下：

1)、客戶端嚮應用A傳送登出Logout請求。 
2)、應用A取消本地會話，同時通知認證中心，使用者已登出。 
3)、應用A返回客戶端登出請求。 
4)、認證中心通知所有使用者登入訪問的應用，使用者已登出。

三、撥開雲霧見青天

1、對上面所有標紅疑問一一解釋

1)、問：系統A是如何發現該請求需要登入重定向到認證中心的？ 
答：使用者通過瀏覽器位址列訪問系統A，系統A(也可以稱為CAS客戶端)去Cookie中拿JSESSION，即在Cookie中維護的當前回話session的id，如果拿到了，說明使用者已經登入，如果未拿到，說明使用者未登入。

2)、問：系統A重定向到認證中心，傳送了什麼資訊或者地址變成了什麼？ 
答：假如系統A的地址為http://a:8080/，CAS認證中心的服務地址為http://cas.server:8080/，那麼重點向前後地址變化為：http://a:8080/————>ttp://cas.server:8080/?service=http://a:8080/，由此可知，重點向到認證中心，認證中心拿到了當前訪問客戶端的地址。

3)、問：登入成功後，認證中心重定向請求到系統A，認證通過令牌是如何附加傳送給系統A的？ 
答：重定向之後的位址列變成：http://a:8080/?ticket=ST-XXXX-XXX，將票據以ticket為引數名的方式通過位址列傳送給系統A

4)、問：系統A驗證令牌，怎樣操作證明使用者登入的？ 
答：系統A通過位址列獲取ticket的引數值ST票據，然後從後臺將ST傳送給CAS server認證中心驗證，驗證ST有效後，CAS server返回當前使用者登入的相關資訊，系統A接收到返回的使用者資訊，併為該使用者建立session會話，會話id由cookie維護，來證明其已登入。

5)、問：登入B系統，認證中心是如何判斷使用者已經登入的？ 
答：在系統A登入成功後，使用者和認證中心之間建立起了全域性會話，這個全域性會話就是TGT(Ticket Granting Ticket)，TGT位於CAS伺服器端，TGT並沒有放在Session中，也就是說，CAS全域性會話的實現並沒有直接使用Session機制，而是利用了Cookie自己實現的，這個Cookie叫做TGC(Ticket Granting Cookie)，它存放了TGT的id,儲存在使用者瀏覽器上。 
相關內容分析可以檢視：《SSO CAS單點系列》之 實操！輕鬆玩轉SSO CAS就這麼簡單(相識篇)

使用者傳送登入系統B的請求，首先會去Cookie中拿JSESSION，因為系統B並未登入過，session會話還未建立，JSESSION的值是拿不到的，然後將請求重定向到CAS認證中心，CAS認證中心先去使用者瀏覽器中拿TGC的值，也就是全域性會話id，如果存在則代表使用者在認證中心已經登入，附帶上認證令牌重定向到系統B。

上面登入狀態判斷也是這個邏輯。

6)、問：登出的過程，各個系統對當前使用者都做了什麼？ 
答：認證中心清除當前使用者的全域性會話TGT，同時清掉cookie中TGT的id：TGC； 
然後是各個客戶端系統，比如系統A、系統B，清除區域性會話session，同時清掉cookie中session會話id：jsession

2、對系統A登入流程圖新增註釋，檢視

不管了，反正我看懂了。

ps：看到這裡的福利，cas系列介紹文章分享：CAS介紹資源頁面

 

原文轉自：https://blog.csdn.net/javaloveiphone/article/details/52439613