CAS單點登錄原理解析



基于Cookie的單點登錄核心原理:

將用戶名密碼加密之后存于Cookie中,之后訪問網站時在過濾器(filter)中校驗用戶權限,如果沒有權限則從Cookie中取出用戶名密碼進行登錄,讓用戶從某種意義上覺得只登錄了一次。

該方式缺點就是多次傳送用戶名密碼,增加被盜風險,以及不能跨域。同時www.qiandu.com與mail.qiandu.com同時擁有登錄邏輯的代碼,如果涉及到修改操作,則需要修改兩處。

2、統(tǒng)一認證中心方案原理

在生活中我們也有類似的相關生活經驗,例如你去食堂吃飯,食堂打飯的阿姨(www.qiandu.com)告訴你,不收現金。并且告訴你,你去門口找換票的(passport.com)換小票。于是你換完票之后,再去找食堂阿姨,食堂阿姨拿著你的票,問門口換票的,這個票是真的嗎?換票的說,是真的,于是給你打飯了。

基于上述生活中的場景,我們將基于Cookie的單點登錄改良以后的方案如下:


經過分析,Cookie單點登錄認證太過于分散,每個網站都持有一份登陸認證代碼。于是我們將認證統(tǒng)一化,形成一個獨立的服務。當我們需要登錄操作時,則重定向到統(tǒng)一認證中心http://passport.com。于是乎整個流程就如上圖所示:

第一步:用戶訪問www.qiandu.com。過濾器判斷用戶是否登錄,沒有登錄,則重定向(302)到網站http://passport.com。

第二步:重定向到passport.com,輸入用戶名密碼。passport.com將用戶登錄的信息記錄到服務器的session中。

第三步:passport.com給瀏覽器發(fā)送一個特殊的憑證,瀏覽器將憑證交給www.qiandu.com,www.qiandu.com則拿著瀏覽器交給他的憑證去passport.com驗證憑證是否有效,從而判斷用戶是否登錄成功。

第四步:登錄成功,瀏覽器與網站之間進行正常的訪問。

3、Yelu大學研發(fā)的CAS(Central Authentication Server)

下面就以耶魯大學研發(fā)的CAS為分析依據,分析其工作原理。首先看一下最上層的項目部署圖:


部署項目時需要部署一個獨立的認證中心(cas.qiandu.com),以及其他N個用戶自己的web服務。

認證中心:也就是cas.qiandu.com,即cas-server。用來提供認證服務,由CAS框架提供,用戶只需要根據業(yè)務實現認證的邏輯即可。

用戶web項目:只需要在web.xml中配置幾個過濾器,用來保護資源,過濾器也是CAS框架提供了,即cas-client,基本不需要改動可以直接使用。

4、CAS的詳細登錄流程


上圖是3個登錄場景,分別為:第一次訪問www.qiandu.com、第二次訪問、以及登錄狀態(tài)下第一次訪問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發(fā)現用戶沒有登錄,則返回瀏覽器重定向地址。


首先可以看到我們請求www.qiandu.com,之后瀏覽器返回狀態(tài)碼302,然后讓瀏覽器重定向到cas.qiandu.com并且通過get的方式添加參數service,該參數目的是登錄成功之后會要重定向回來,因此需要該參數。并且你會發(fā)現,其實server的值就是編碼之后的我們請求www.qiandu.com的地址。

標號3:瀏覽器接收到重定向之后發(fā)起重定向,請求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的關系。

TGT:Ticket Granted Ticket(俗稱大令牌,或者說票根,他可以簽發(fā)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的環(huán)節(jié)是通過代碼調用的,并不是瀏覽器發(fā)起,所以沒有截取到報文。

4.2、第二次訪問www.qiandu.com

上面以及訪問過一次了,當第二次訪問的時候發(fā)生了什么呢?

標號11:用戶發(fā)起請求,訪問www.qiandu.com。會經過cas-client,也就是過濾器,因為第一次訪問成功之后www.qiandu.com中會在session中記錄用戶信息,因此這里直接就通過了,不用驗證了。

標號12:用戶通過權限驗證,瀏覽器返回正常資源。

4.3、訪問mail.qiandu.com

標號13:用戶在www.qiandu.com正常上網,突然想訪問mail.qiandu.com,于是發(fā)起訪問mail.qiandu.com的請求。

標號14:mail.qiandu.com接收到請求,發(fā)現第一次訪問,于是給他一個重定向的地址,讓他去找認證中心登錄。


上圖可以看到,用戶請求mail.qiandu.com,然后返回給他一個網址,狀態(tài)302重定向,service參數就是回來的地址。

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

標號16:認證中心收到請求,發(fā)現TGC對應了一個TGT,于是用TGT簽發(fā)一個ST,并且返回給瀏覽器,讓他重定向到mail.qiandu.com


可以發(fā)現請求的時候是攜帶Cookie:CASTGC的,響應的就是一個地址加上TGT簽發(fā)的ST也就是ticket。

標號17:瀏覽器根據16返回的網址發(fā)起重定向。

標號18:mail.qiandu.com獲取ticket去認證中心驗證是否有效。

標號19:認證成功,返回在mail.qiandu.com的session中設置登錄狀態(tài),下次就直接登錄。

標號20:認證成功之后就反正用想要訪問的資源了。


最后編輯于
?著作權歸作者所有,轉載或內容合作請聯(lián)系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發(fā)布,文章內容僅代表作者本人觀點,簡書系信息發(fā)布平臺,僅提供信息存儲服務。

推薦閱讀更多精彩內容