簡單登錄

client:提供用戶名和密碼或者是其他的認證憑證

server:驗證client提供的認證憑證,記錄登錄狀態

過程:訪問系統時,client必須輸入用戶名和密碼,server進行驗證,驗證通過後server建立一個叫做session的東西,然後把sessionId通過cookie發送給瀏覽器,下次登錄的時候會帶著cookie一起發過來,server從cookie中拿到sessionId就知道已經登錄啦。

 cookie和session的作用就是保持client和server的交互狀態,這樣一來可以將無狀態的通信轉化成有狀態的交互,也就是讓server有了「記憶」能力。

多系統登錄

現在有三個服務,需要輸入三次用戶資訊,但是如果有成百上千的服務呢?HOW???

參考上面簡單登錄的原理:服務端如何有了「記憶」能力呢:在client和server之間引入了一個中間層(cookie或者是session)。(題外話:計算機世界的99%的問題都可以通過一個引入一個中間層來解決)

所有我們可以想到一個可行的解決方案:對這個「中間層」做共享。

比如說先登錄了A,就有了一個cookie,然後在用cookie去登錄其他的系統。但是這樣明顯是有問題的:

1,cookie不能跨域,比如說a.com產生的cookie是不能傳遞給b.com的

2,就算cookie可以傳遞,但是其他系統並沒有session來校驗這個cookie。

解決方案:

1.cookie做共享可以掛到同一個一級域名下,比如A叫a.corp.com,B叫b.corp.com,C叫c.corp.com,這樣cookie不就能共享了嘛

2,將session也做共享,從內存裡面拿出來,放入一個大家都能訪問的中間層裡面,比如說redis。(題外話:又是中間層)

像下面這樣:

可以解決多系統登錄的問題么?可以解決!!! 但是

1,要共享cookie就必須讓所有的系統都在同一個域名下

2,多用戶賬號的存在。比如張三登錄了A,然後去登錄B,通過這種方式的話B需要去校驗張三這個用戶的合法性,此張三可能未必是彼張三!各個業務系統必須自己去維護自己系統的用戶,而且用戶資訊還不止一個。

HOW????

SSO

Single Sign One :單點登錄

消除多用戶資訊的問題,不用各個業務系統自己去維護用戶資訊,建立一個統一的用戶認證中心(中間層:又是我哈哈哈),所有用戶的認證工作都交給這個認證中心來完成。各個子業務只需要負責實現自己的業務即可,不在需要關心用戶、認證等細節。

大致流程如下:

用戶第一次訪問A系統:www.a.corp.com,這個時候如果A發現用戶沒有登錄的話,那他需要做的一項操作就是重定向認證中心:www.sso.com/login?redirect=www.a.corp.com。

其中www.sso.com/login就是認證中心的登錄地址,redirect=www.a.corp.com就是登錄完成後需要跳轉到的地址。在認證中心登錄之後認證中心會做以下幾件事情:

1,建立一個session

2,發放ticket

3,重定向到你的地址,並在瀏覽器種下cookie資訊。注意這個cookie是認證中心服務器的cookie哦。如:ssoid=1,domain=sso.com

需要注意的有兩點:

1,進行了兩次重定向。第一次是重定向到SSO的服務器,第二次是重定向我們的後端服務器。

2,流程完成後再瀏覽器種了兩個cookie,一個是sso服務器的cookie,一個是子系統A的cookie。

接下來我們訪問B系統:

這個時候會有三個cookie:

1,認證中心的cookie    domain:   sso.com  

2,A系統的cookie    domain: a.corp.com

3, B系統的cookie     domain: b.corp.com

本質上就是保存了一個認證中心的cookie和多個子系統的cookie。一般我們稱SSO的cookie的對應的會話成為全局會話,各自子系統cookie對應的會話稱為局部會話。

解決方案(CAS)

概述

CAS(Central Authentication Service) 是 Yale 大學發起的一個企業級的、開源的項目,旨在為 Web 應用系統提供一種可靠的單點登錄解決方法(屬於 Web SSO)。

CAS 開始於 2001 年, 並在 2004 年 12 月正式成為 JA-SIG 的一個項目。

特性

1、  開源的、多協議的 SSO 解決方案;Protocols:Custom Protocol、CAS、OAuth、OpenID、RESTful API、SAML1.1、SAML2.0 等。

2、  支持多種認證機制:Active Directory、JAAS、JDBC、LDAP、X.509 Certificates 等;

3、  安全策略:使用票據(Ticket)來實現支持的認證協議;

4、  支持授權:可以決定哪些服務可以請求和驗證服務票據(Service Ticket);

5、  提供高可用性:通過把認證過的狀態數據存儲在 TicketRegistry 組件中,這些組件有很多支持分散式環境的實現,如:BerkleyDB、Default 、EhcacheTicketRegistry、JDBCTicketRegistry、JBOSS TreeCache、JpaTicketRegistry、MemcacheTicketRegistry 等;

6、  支持多種客戶端: Java、 .Net、 PHP、 Perl、 Apache, uPortal 等。

體繫結構 

從結構上看,CAS 包含兩個部分:CAS Server 和 CAS Client,CAS 需要獨立部署,主要負責對用戶的認證工作,CAS Server 會處理用戶名 / 密碼等憑證 (Credentials)。

負責處理對客戶端受保護資源的訪問請求,需要對請求方進行身份認證時,重定向到 CAS Server 進行認證。CAS Client一般與 與受保護的客戶端應用部署在一起,以 Filter 方式保護受保護的資源。過濾從客戶端過來的每一個 Web 請求,同時, CAS Client 會分析 HTTP 請求中是否包請求 Service Ticket

術語

 Ticket Granting ticket (TGT) :可以認為是CAS Server根據用戶名密碼生成的一張票,存在server端

Ticket-granting cookie (TGC) :其實就是一個cookie,存放用戶身份資訊,由server發給client端

Service ticket (ST) :由TGT生成的一次性票據,用於驗證,只能用一次。相當於server發給client一張票,然後client拿著這是個票再來找server驗證,看看是不是server簽發的。就像是我給了你一張我的照片,然後你拿照片再來問我,這個照片是不是你。。。沒錯,就是這么無聊。

安全性

TGC安全性:

對於一個 CAS 用戶來說,最重要是要保護它的 TGC,如果 TGC 不慎被 CAS Server 以外的實體獲得,Hacker 能夠找到該 TGC,然後冒充 CAS 用戶訪問所有授權資源。從基礎模式可以看出, TGC 是 CAS Server 通過 SSL 方式發送給終端用戶,因此,要截取 TGC 難度非常大,從而確保 CAS 的安全性。TGT 的存活周期默認為 120 分鐘。

ST安全性:

ST(Service Ticket)是通過 Http 傳送的,因此網路中的其他人可以 Sniffer 到其他人的 Ticket。CAS 通過以下幾方面來使 ST 變得更加安全:

1、  ST 只能使用一次

CAS 協議規定,無論 Service Ticket 驗證是否成功, CAS Server 都會清除服務端緩存中的該 Ticket,從而可以確保一個 Service Ticket 不被使用兩次。

2、  ST 在一段時間內失效

CAS 規定 ST 只能存活一定的時間,然後 CAS Server 會讓它失效。默認有效時間為 5 分鐘。

3、  ST 是基於隨機數生成的

ST 必須足夠隨機,如果 ST 生成規則被猜出,Hacker 就等於繞過 CAS 認證,直接訪問對應的服務。

流程

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

第一次訪問www.qiandu.com

標號1:用戶訪問http://www.qiandu.com,經過他的第一個過濾器:org.jasig.cas.client.authentication.AuthenticationFilter(cas提供,在web.xml中配置)。主要作用:判斷是否登錄,如果沒有登錄則重定向到認證中心

標號2:www.qiandu.com發現用戶沒有登錄,則返回瀏覽器重定向地址。

首先可以看到我們請求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的關系。點擊這里了解Java如何操作Cookie。

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有效。

標號10:www.qiandu.com接收到cas-server的返回,知道了用戶合法,展示相關資源到用戶瀏覽器上。

第二次訪問www.qiandu.com

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

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

訪問mail.qiandu.com

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

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

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

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

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

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

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

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

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

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

Demo演示

配置filter

 我們需要在應用的web.xml文件中配置四個Filter,這四個Filter必須按照固定的順序來進行配置,而且它們必須配置在應用的其它Filter之前。它們的先後順序要求如下:

1、AuthenticationFilter

casServerLoginUrl用來指定Cas Server登錄地址,serverName或service用來指定認證成功後需要跳轉地址。

2、TicketValidationFilter

      請求通過AuthenticationFilter的認證之後,如果請求中攜帶了參數ticket則將會由TicketValidationFilter來對攜帶的ticket進行校驗。 TicketValidationFilter只是對驗證ticket的這一類Filter的統稱,其並不對應Cas Client中的一個具體類型。Cas Client中有多種驗證ticket的Filter,

都繼承自AbstractTicketValidationFilter,它們的驗證邏輯都是一致的,都有AbstractTicketValidationFilter實現,不同的是使用的TicketValidator不一樣。這里我們使用Cas10TicketValidationFilter,也可以使用Cas20ProxyReceivingTicketValidationFilter或Saml11TicketValidationFilter。

3、HttpServletRequestWrapperFilter

 HttpServletRequestWrapperFilter用於將每一個請求對應的HttpServletRequest封裝為其內部定義的CasHttpServletRequestWrapper,該封裝類將利用之前保存在Session或request中的Assertion對象重寫HttpServletRequest的getUserPrincipal()、getRemoteUser()和isUserInRole()方法。

      這樣在我們的應用中就可以非常方便的從HttpServletRequest中獲取到用戶的相關資訊

4、AssertionThreadLocalFilter

AssertionThreadLocalFilter可以在應用的其它地方獲取Assertion對象,找個過濾器會把Assertion對象存放到當前的線程變量中,我們在程序的任何地方都可以從線程變量中獲取當前Assertion,就不需要再從Session或request中進行解析了。這個線程變量是由AssertionHolder持有的,我們在獲取當前的        Assertion時也只需要通過AssertionHolder的getAssertion()方法獲取即可