一,業(yè)務(wù)分析

在分布式系統(tǒng)架構(gòu)中,假設(shè)把上述的三個子系統(tǒng)部署在三個不同的服務(wù)器上。前提是用戶登錄之后才能訪問這些子系統(tǒng)。那么使用傳統(tǒng)方式,可能會存在這樣的問題:
1.當訪問用戶中心,需要用戶登錄帳號
2.當訪問購物車,還需要用戶登錄帳號
3.當訪問商品結(jié)算,又一次需要用戶登錄帳號
訪問每一個子系統(tǒng)都需要用戶登錄帳號,這樣的體驗對于用戶來說是極差。而使用單點登錄就可以很好地解決上述的問題。
二,單點登錄
單點登錄(Single Sign On),簡稱為 SSO,是目前比較流行的企業(yè)業(yè)務(wù)整合的解決方案之一。SSO 的定義是在多個應(yīng)用系統(tǒng)中,用戶只需要登錄一次就可以訪問所有相互信任的應(yīng)用系統(tǒng)。
我們目前的系統(tǒng)存在諸多子系統(tǒng),而這些子系統(tǒng)是分別部署在不同的服務(wù)器中,那么使用傳統(tǒng)方式的 session 是無法解決的,我們需要使用相關(guān)的單點登錄技術(shù)來解決。
第一步:用戶訪問應(yīng)用系統(tǒng)1。過濾器判斷用戶是否登錄,沒有登錄,則重定向(302)到認證系統(tǒng)去進行認證操作。
第二步:重定向到認證系統(tǒng),顯示登錄界面,用戶輸入用戶名密碼。認證系統(tǒng)將用戶登錄的信息記錄到服務(wù)器的session中。
第三步:認證系統(tǒng)給瀏覽器發(fā)送一個特殊的憑證ticket,瀏覽器將憑證交給應(yīng)用系統(tǒng)1,應(yīng)用系統(tǒng)1則拿著瀏覽器交給他的憑證ticket去認證系統(tǒng)驗證憑證ticket是否有效。憑證ticket若是有效,將用戶信息保存到應(yīng)用系統(tǒng)1的session中一份,并告知應(yīng)用系統(tǒng)1,用戶通過認證。
第四步:用戶通過認證,瀏覽器與網(wǎng)站之間進行正常的訪問。
第五步:當用戶再次訪問應(yīng)用系統(tǒng)1,由于應(yīng)用系統(tǒng)1的session中有用戶信息,所以就不用經(jīng)過認證系統(tǒng)認證,就可以直接訪問應(yīng)用系統(tǒng)1了。
第六步:當用戶再去訪問其他應(yīng)用系統(tǒng)時,瀏覽器會帶著憑證ticket過去,其他應(yīng)用系統(tǒng)到認證系統(tǒng)驗證憑證,憑證ticket若是有效,將用戶信息保存到其他應(yīng)用系統(tǒng)的session中一份,并告知其他應(yīng)用系統(tǒng),用戶通過認證。
第七步:用戶通過認證,瀏覽器與網(wǎng)站之間進行正常的訪問。
第八步:當用戶再次訪問其他應(yīng)用系統(tǒng),由于其他應(yīng)用系統(tǒng)的session中有用戶信息,所以就不用經(jīng)過認證系統(tǒng)認證,就可以直接訪問其他應(yīng)用系統(tǒng)了。
三、Yelu大學(xué)研發(fā)的CAS(Central Authentication Server)
1.什么是CAS?
CAS 是 Yale 大學(xué)發(fā)起的一個開源項目,旨在為 Web 應(yīng)用系統(tǒng)提供一種可靠的單點登錄方法,CAS 在 2004 年 12 月正式成為 JA-SIG 的一個項目。CAS 具有以下特點:
【1】開源的企業(yè)級單點登錄解決方案。
【2】CAS Server 為需要獨立部署的 Web 應(yīng)用。這個CAS框架已經(jīng)提供
【3】CAS Client 支持非常多的客戶端(這里指單點登錄系統(tǒng)中的各個 Web 應(yīng)用),包括Java, .Net, PHP, Perl, Apache, uPortal, Ruby 等。
從結(jié)構(gòu)上看,CAS 包含兩個部分: CAS Server 和 CAS Client。CAS Server 需要獨立部署,主要負責對用戶的認證工作;CAS Client 負責處理對客戶端受保護資源的訪問請求,需要登錄時,重定向到 CAS Server。下圖是 CAS 最基本的協(xié)議過程:
2.CAS的詳細登錄流程
該圖主要描述
1.第一次訪問http://shopping.xiaogui.com
2.在登錄狀態(tài)下第二次訪問http://shopping.xiaogui.com
3.在登錄狀態(tài)下第一次訪問http://pay.xiaogui.com
下面對圖中序號代表的操作進行說明
當用戶第一次訪問http://shopping.xiaogui.com
序號1:用戶請求http://shopping.xiaogui.com,會經(jīng)過AuthenticationFilter認證過濾器(在cas client 的web.xml中配置)
主要作用:判斷是否登錄,如果沒有登錄則重定向到認證中心。
大概知道這個就行,CAS的具體實現(xiàn)會在以后的博客中寫道
序號2:?AuthenticationFilter發(fā)現(xiàn)用戶沒有登錄,則返回瀏覽器重定向地址。
重定向的地址就是認證服務(wù)器CAS Server的地址,后面的參數(shù)是我們請求的客戶端地址,這個參數(shù)目的就是為了認證成功以后,根據(jù)這個參數(shù)的地址重定向回請求的客戶端
序號3:?瀏覽器根據(jù)響應(yīng)回來的重定向地址,向cas.xiaogui.com認證系統(tǒng)發(fā)出請求
序號4:?認證系統(tǒng)cas.xiaogui.com接收請求,響應(yīng)登陸頁面
序號5::用戶登陸頁面輸入用戶名密碼,提交請求
序號6::CAS Server 認證服務(wù)器接收用戶名和密碼,就行驗證,驗證邏輯CAS Server 已經(jīng)實現(xiàn),并響應(yīng)給瀏覽器信息
這里的用戶名,密碼不需要關(guān)心,后續(xù)會講到
圖中1,2部分表示序號5 輸入的用戶名,密碼,以及發(fā)出的請求。當認證服務(wù)器驗證通過之后,根據(jù)請求參數(shù)service的值,進行重定向,其實就是回到了請求的客戶端,同時會攜帶一個ticket令牌參數(shù)。同時會在Cookie中設(shè)置一個TGC,該cookie是網(wǎng)站認證系統(tǒng)cas.xiaogui.com的cookie,只有訪問這個網(wǎng)站才會攜帶這個cookie過去。
*****注意:這個攜帶TGC的Cookie是實現(xiàn)CAS單點登錄的關(guān)鍵所在!
Cookie中的TGC:向cookie中添加該值的目的是當下次訪問cas.xiaogui.com認證系統(tǒng)時,瀏覽器將Cookie中的TGC攜帶到服務(wù)器,服務(wù)器根據(jù)這個TGC,查找與之對應(yīng)的TGT。從而判斷用戶是否登錄過了,是否需要展示登錄頁面。TGT與TGC的關(guān)系就像SESSION與Cookie中SESSIONID的關(guān)系。
TGT:Ticket Granted Ticket(俗稱大令牌,或者說票根,他可以簽發(fā)ST)
TGC:Ticket Granted Cookie(cookie中的value),存在Cookie中,根據(jù)他可以找到TGT。
ST:Service Ticket (小令牌),是TGT生成的,默認是用一次就生效了。也就是上面數(shù)字3處的ticket值。
序號7:?客戶端拿到請求中的ticket信息,也就是圖中1的位置
然后經(jīng)過一個ticket過濾器Cas20ProxyReceivingTicketValidationFilter,去認證系統(tǒng)CAS Server判斷ticket是否有效
這個過濾器的主要工作就是校驗客戶端傳過來的ticket是否有效
CAS Client 客戶端?shopping.xiaogui.com?中web.xml的配置
序號8:?向CAS Server認證系統(tǒng)發(fā)出驗證ticket的請求,也就是圖中2的位置,然后執(zhí)行ticket驗證
序號9:?通過校驗之后,把用戶信息保存到客戶端的session中,并把客戶端的SessionID設(shè)置在Cookie中,同時告知客戶端ticket有效。當用戶再次訪問該客戶端,就可以根據(jù)Cookie 中的SessionID找到客戶端的Session,獲取用戶信息,就不用再次進行驗證了。也就是圖中響應(yīng)給瀏覽器的部分。
序號10:?shopping.xiaogui.com客戶端接收到cas-server的返回,知道了用戶已經(jīng)登錄,ticket有效,告知瀏覽器可以進行訪問。

至此,用戶第一次訪問流程結(jié)束。
當用戶第二次訪問http://shopping.xiaogui.com
序號11:當用戶第二次訪問,仍然會經(jīng)過AuthenticationFilter過濾器,但與第一次訪問不同的是此時客戶端session中已經(jīng)存在用戶的信息,瀏覽器中的Cookie會根據(jù)SessionID找到Session,獲取用戶信息,所以不需要進行驗證,可以直接訪問。
序號12:?客戶端告知瀏覽器可以進行訪問。
當用戶第一次訪問http://pay.xiaogui.com
序號13:?用戶向pay.xiaogui.com?CAS Client客戶端發(fā)出請求
序號14:?:pay.xiaogui.com接收到請求,發(fā)現(xiàn)第一次訪問,于是給他一個重定向的地址,讓他去找認證中心登錄。
序號15:瀏覽器根據(jù)上面響應(yīng)的地址,發(fā)起重定向,因為之前訪問過一次了,因此這次會攜帶上次返回的Cookie:TGC到認證中心。
序號16:?認證中心收到請求,發(fā)現(xiàn)TGC對應(yīng)了一個TGT,于是用TGT簽發(fā)一個ticket,并且返回給瀏覽器,讓他重定向到pay.xiaogui.comCAS Client客戶端。
序號17:根據(jù)上面響應(yīng)回來的地址,進行重定向到pay.xiaogui.comCAS Client客戶端
序號18:?pay.xiaogui.comCAS Client客戶端帶著ticket去認證中心驗證是否有效。
序號19:?認證成功,把用戶信息保存到客戶端的session中,并把客戶端的SessionID設(shè)置在Cookie中。當用戶下次訪問pay.xiaogui.comCAS Client客戶端,直接登錄,無需驗證。
序號20:?告知瀏覽器可以進行訪問


CAS單點登錄的原理分析大致就是上述的這些,至于CAS單點登錄的具體實現(xiàn),將在下篇博客中寫道。