1. 程式人生 > >CAS單點登入原理分析

CAS單點登入原理分析

一,業務分析

在這裡插入圖片描述

在分散式系統架構中,假設把上述的三個子系統部署在三個不同的伺服器上。前提是使用者登入之後才能訪問這些子系統。那麼使用傳統方式,可能會存在這樣的問題: 1.當訪問使用者中心,需要使用者登入帳號 2.當訪問購物車,還需要使用者登入帳號 3.當訪問商品結算,又一次需要使用者登入帳號

訪問每一個子系統都需要使用者登入帳號,這樣的體驗對於使用者來說是極差。而使用單點登入就可以很好地解決上述的問題。

二,單點登入

單點登入(Single Sign On),簡稱為 SSO,是目前比較流行的企業業務整合的解決方案之一。SSO 的定義是在多個應用系統中,使用者只需要登入一次就可以訪問所有相互信任的應用系統。 我們目前的系統存在諸多子系統,而這些子系統是分別部署在不同的伺服器中,那麼使用傳統方式的 session 是無法解決的,我們需要使用相關的單點登入技術來解決。

在這裡插入圖片描述

第一步:使用者訪問應用系統1。過濾器判斷使用者是否登入,沒有登入,則重定向(302)到認證系統去進行認證操作。

第二步:重定向到認證系統,顯示登入介面,使用者輸入使用者名稱密碼。認證系統將使用者登入的資訊記錄到伺服器的session中。

第三步:認證系統給瀏覽器傳送一個特殊的憑證ticket,瀏覽器將憑證交給應用系統1,應用系統1則拿著瀏覽器交給他的憑證ticket去認證系統驗證憑證ticket是否有效。憑證ticket若是有效,將使用者資訊儲存到應用系統1的session中一份,並告知應用系統1,使用者通過認證。

第四步:使用者通過認證,瀏覽器與網站之間進行正常的訪問。

第五步:當用戶再次訪問應用系統1,由於應用系統1的session中有使用者資訊,所以就不用經過認證系統認證,就可以直接訪問應用系統1了。

第六步:當用戶再去訪問其他應用系統時,瀏覽器會帶著憑證ticket過去,其他應用系統到認證系統驗證憑證,憑證ticket若是有效,將使用者資訊儲存到其他應用系統的session中一份,並告知其他應用系統,使用者通過認證。

第七步:使用者通過認證,瀏覽器與網站之間進行正常的訪問。

第八步:當用戶再次訪問其他應用系統,由於其他應用系統的session中有使用者資訊,所以就不用經過認證系統認證,就可以直接訪問其他應用系統了。

三、Yelu大學研發的CAS(Central Authentication Server)

1.什麼是CAS?

CAS 是 Yale 大學發起的一個開源專案,旨在為 Web 應用系統提供一種可靠的單點登入方法,CAS 在 2004 年 12 月正式成為 JA-SIG 的一個專案。CAS 具有以下特點: 【1】開源的企業級單點登入解決方案。 【2】CAS Server 為需要獨立部署的 Web 應用。這個CAS框架已經提供 【3】CAS Client 支援非常多的客戶端(這裡指單點登入系統中的各個 Web 應用),包括Java, .Net, PHP, Perl, Apache, uPortal, Ruby 等。

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

在這裡插入圖片描述

2.CAS的詳細登入流程

在這裡插入圖片描述

該圖主要描述 1.第一次訪問http://shopping.xiaogui.com 2.在登入狀態下第二次訪問http://shopping.xiaogui.com 3.在登入狀態下第一次訪問http://pay.xiaogui.com

下面對圖中序號代表的操作進行說明

當用戶第一次訪問http://shopping.xiaogui.com

序號1:使用者請求http://shopping.xiaogui.com,會經過AuthenticationFilter認證過濾器(在cas client 的web.xml中配置)

主要作用:判斷是否登入,如果沒有登入則重定向到認證中心。 在這裡插入圖片描述

大概知道這個就行,CAS的具體實現會在以後的部落格中寫道

序號2: AuthenticationFilter發現使用者沒有登入,則返回瀏覽器重定向地址。 在這裡插入圖片描述

重定向的地址就是認證伺服器CAS Server的地址,後面的引數是我們請求的客戶端地址,這個引數目的就是為了認證成功以後,根據這個引數的地址重定向回請求的客戶端

序號3: 瀏覽器根據響應回來的重定向地址,向cas.xiaogui.com認證系統發出請求

序號4: 認證系統cas.xiaogui.com接收請求,響應登陸頁面

序號5::使用者登陸頁面輸入使用者名稱密碼,提交請求

序號6::CAS Server 認證伺服器接收使用者名稱和密碼,就行驗證,驗證邏輯CAS Server 已經實現,並響應給瀏覽器資訊 在這裡插入圖片描述

這裡的使用者名稱,密碼不需要關心,後續會講到

在這裡插入圖片描述

圖中1,2部分表示序號5 輸入的使用者名稱,密碼,以及發出的請求。當認證伺服器驗證通過之後,根據請求引數service的值,進行重定向,其實就是回到了請求的客戶端,同時會攜帶一個ticket令牌引數。同時會在Cookie中設定一個TGC,該cookie是網站認證系統cas.xiaogui.com的cookie,只有訪問這個網站才會攜帶這個cookie過去。

*****注意:這個攜帶TGC的Cookie是實現CAS單點登入的關鍵所在!

Cookie中的CASTGC:向cookie中新增該值的目的是當下次訪問cas.xiaogui.com認證系統時,瀏覽器將Cookie中的TGC攜帶到伺服器,伺服器根據這個CASTGC,查詢與之對應的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: 客戶端拿到請求中的ticket資訊,也就是圖中1的位置 在這裡插入圖片描述

然後經過一個ticket過濾器Cas20ProxyReceivingTicketValidationFilter,去認證系統CAS Server判斷ticket是否有效

這個過濾器的主要工作就是校驗客戶端傳過來的ticket是否有效

在這裡插入圖片描述

序號8: 向CAS Server認證系統發出驗證ticket的請求,也就是圖中2的位置,然後執行ticket驗證

序號9: 通過校驗之後,把使用者資訊儲存到客戶端的session中,並把客戶端的SessionID設定在Cookie中,同時告知客戶端ticket有效。當用戶再次訪問該客戶端,就可以根據Cookie 中的SessionID找到客戶端的Session,獲取使用者資訊,就不用再次進行驗證了。也就是圖中響應給瀏覽器的部分。

序號10: shopping.xiaogui.com客戶端接收到cas-server的返回,知道了使用者已經登入,ticket有效,告知瀏覽器可以進行訪問。

在這裡插入圖片描述

在這裡插入圖片描述

至此,使用者第一次訪問流程結束。

當用戶第二次訪問http://shopping.xiaogui.com

序號11:當用戶第二次訪問,仍然會經過AuthenticationFilter過濾器,但與第一次訪問不同的是此時客戶端session中已經存在使用者的資訊,瀏覽器中的Cookie會根據SessionID找到Session,獲取使用者資訊,所以不需要進行驗證,可以直接訪問。

序號12: 客戶端告知瀏覽器可以進行訪問。

當用戶第一次訪問http://pay.xiaogui.com

序號14: :pay.xiaogui.com接收到請求,發現第一次訪問,於是給他一個重定向的地址,讓他去找認證中心登入。

在這裡插入圖片描述

序號15:瀏覽器根據上面響應的地址,發起重定向,因為之前訪問過一次了,因此這次會攜帶上次返回的Cookie:TGC到認證中心。

序號16: 認證中心收到請求,發現TGC對應了一個TGT,於是用TGT簽發一個ticket,並且返回給瀏覽器,讓他重定向到pay.xiaogui.comCAS Client客戶端。

在這裡插入圖片描述

序號17:根據上面響應回來的地址,進行重定向到pay.xiaogui.comCAS Client客戶端

序號18: pay.xiaogui.comCAS Client客戶端帶著ticket去認證中心驗證是否有效。

序號19: 認證成功,把使用者資訊儲存到客戶端的session中,並把客戶端的SessionID設定在Cookie中。當用戶下次訪問pay.xiaogui.comCAS Client客戶端,直接登入,無需驗證。

在這裡插入圖片描述

序號20: 告知瀏覽器可以進行訪問

在這裡插入圖片描述 在這裡插入圖片描述

CAS單點登入的原理分析大致就是上述的這些,至於CAS單點登入的具體實現,將在下篇部落格中寫道。