CAS實現單點登入SSO執行原理探究

yshir-phper發表於2020-11-22

一、不落俗套的開始

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登入流程圖新增註釋,檢視

這裡寫圖片描述

 

相關文章