CAS單點登入(理論部分)

2022-11-27 09:27:38 字數 3258 閱讀 2211

基於cookie的單點登入核心原理:

將使用者名稱密碼加密之後存於cookie中,之後訪問**時在過濾器(filter)中校驗使用者許可權,如果沒有許可權則從cookie中取出使用者名稱密碼進行登入,讓使用者從某種意義上覺得只登入了一次。

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

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

基於上述生活中的場景,我們將基於cookie的單點登入改良以後的方案如下:

經過分析,cookie單點登入認證太過於分散,每個**都持有一份登陸認證**。於是我們將認證統一化,形成一個獨立的服務。當我們需要登入操作時,則重定向到統一認證中心於是乎整個流程就如上圖所示:

第一步:使用者訪問www.qiandu.com。過濾器判斷使用者是否登入,沒有登入,則重定向(302)到**

第二步:重定向到passport.com,輸入使用者名稱密碼。passport.com將使用者登入的資訊記錄到伺服器的session中。

第三步:passport.com給瀏覽器傳送一個特殊的憑證,瀏覽器將憑證交給www.qiandu.com,www.qiandu.com則拿著瀏覽器交給他的憑證去passport.com驗證憑證是否有效,從而判斷使用者是否登入成功。

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

下面就以耶魯大學研發的cas為分析依據,分析其工作原理。首先看一下最上層的專案部署圖:

部署專案時需要部署一個獨立的認證中心(cas.qiandu.com),以及其他n個使用者自己的web服務。

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

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

上圖是3個登入場景,分別為:第一次訪問www.qiandu.com、第二次訪問、以及登入狀態下第一次訪問mail.qiandu.com。

下面就詳細說明上圖中每個數字標號做了什麼,以及相關的請求內容,響應內容。

標號1:使用者訪問經過他的第一個過濾器(cas提供,在web.xml中配置)authenticationfilter。

過濾器全稱:org.jasig.cas.client.authentication.authenticationfilter

主要作用:判斷是否登入,如果沒有登入則重定向到認證中心。

首先可以看到我們請求www.qiandu.com,之後瀏覽器返回狀態碼302,然後讓瀏覽器重定向到cas.qiandu.com並且通過get的方式新增引數service,該引數目的是登入成功之後會要重定向回來,因此需要該引數。並且你會發現,其實server的值就是編碼之後的我們請求www.qiandu.com的地址。

標號3:瀏覽器接收到重定向之後發起重定向,請求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(俗稱大令牌,或者說票根,他可以簽發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有效。

至此,第一次訪問的整個流程結束,其中標號8與標號9的環節是通過**呼叫的,並不是瀏覽器發起,所以沒有擷取到報文。

上面以及訪問過一次了,當第二次訪問的時候發生了什麼呢?

標號11:使用者發起請求,訪問www.qiandu.com。會經過cas-client,也就是過濾器,因為第一次訪問成功之後www.qiandu.com中會在session中記錄使用者資訊,因此這裡直接就通過了,不用驗證了。

標號12:使用者通過許可權驗證,瀏覽器返回正常資源。

標號13:使用者在www.qiandu.com正常上網,突然想訪問mail.qiandu.com,於是發起訪問mail.qiandu.com的請求。

標號16:認證中心收到請求,發現tgc對應了一個tgt,於是用tgt簽發一個st,並且返回給瀏覽器,讓他重定向到mail.qiandu.com

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

標號19:認證成功,返回在mail.qiandu.com的session中設定登入狀態,下次就直接登入。

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

至此,cas登入的整個過程就完畢了,以後有時間總結下如何使用cas,並運用到專案中。