1.??????CAS?簡(jiǎn)介

1.1.??What is CAS?？

CAS?（?Central Authentication Service?） 是?Yale?大學(xué)發(fā)起的一個(gè)企業(yè)級(jí)的、開源的項(xiàng)目，旨在為?Web?應(yīng)用系統(tǒng)提供一種可靠的單點(diǎn)登錄解決方法（屬于?Web SSO?）。

CAS?開始于?2001?年， 并在?2004?年?12?月正式成為?JA-SIG?的一個(gè)項(xiàng)目。

1.2.??主要特性

1、???開源的、多協(xié)議的?SSO?解決方案；?Protocols?：?Custom Protocol?、?CAS?、?OAuth?、?OpenID?、?RESTful API?、?SAML1.1?、?SAML2.0?等。

2、???支持多種認(rèn)證機(jī)制：?Active Directory?、?JAAS?、?JDBC?、?LDAP?、?X.509 Certificates等；

3、???安全策略：使用票據(jù)（?Ticket?）來實(shí)現(xiàn)支持的認(rèn)證協(xié)議；

4、???支持授權(quán)：可以決定哪些服務(wù)可以請(qǐng)求和驗(yàn)證服務(wù)票據(jù)（?Service Ticket?）；

5、???提供高可用性：通過把認(rèn)證過的狀態(tài)數(shù)據(jù)存儲(chǔ)在?TicketRegistry?組件中，這些組件有很多支持分布式環(huán)境的實(shí)現(xiàn)，如：?BerkleyDB?、?Default?、?EhcacheTicketRegistry?、?JDBCTicketRegistry?、?JBOSS TreeCache?、?JpaTicketRegistry?、?MemcacheTicketRegistry?等；

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

?

2.??????SSO?單點(diǎn)登錄原理

本文內(nèi)容主要針對(duì)?Web SSO?。

2.1.??什么是SSO

單點(diǎn)登錄（?Single Sign-On ,?簡(jiǎn)稱?SSO?）是目前比較流行的服務(wù)于企業(yè)業(yè)務(wù)整合的解決方案之一，?SSO?使得在多個(gè)應(yīng)用系統(tǒng)中，用戶只需要?登錄一次?就可以訪問所有相互信任的應(yīng)用系統(tǒng)。

2.2.??SSO?原理

2.2.1.??????SSO?體系中的角色

一般?SSO?體系主要角色有三種：

1、?User?（多個(gè)）

2、?Web?應(yīng)用（多個(gè)）

3、?SSO?認(rèn)證中心（?1?個(gè)?）

2.2.2.??????SSO?實(shí)現(xiàn)模式的原則

SSO?實(shí)現(xiàn)模式一般包括以下三個(gè)原則：

1、???所有的認(rèn)證登錄都在?SSO?認(rèn)證中心進(jìn)行；

2、???SSO?認(rèn)證中心通過一些方法來告訴?Web?應(yīng)用當(dāng)前訪問用戶究竟是不是已通過認(rèn)證的用戶；

3、???SSO?認(rèn)證中心和所有的?Web?應(yīng)用建立一種信任關(guān)系，也就是說?web?應(yīng)用必須信任認(rèn)證中心。（單點(diǎn)信任）

2.2.3.??????SSO?主要實(shí)現(xiàn)方式

SSO?的主要實(shí)現(xiàn)方式有：

1、???共享?cookies

基于共享同域的?cookie?是?Web?剛開始階段時(shí)使用的一種方式，它利用瀏覽同域名之間自動(dòng)傳遞?cookies?機(jī)制，實(shí)現(xiàn)兩個(gè)域名之間系統(tǒng)令牌傳遞問題；另外，關(guān)于跨域問題，雖然?cookies本身不跨域，但可以利用它實(shí)現(xiàn)跨域的?SSO?。如：代理、暴露?SSO?令牌值等。

缺點(diǎn)：不靈活而且有不少安全隱患，已經(jīng)被拋棄。

2、???Broker-based(?基于經(jīng)紀(jì)人?)

這種技術(shù)的特點(diǎn)就是，有一個(gè)集中的認(rèn)證和用戶帳號(hào)管理的服務(wù)器。經(jīng)紀(jì)人給被用于進(jìn)一步請(qǐng)求的電子身份存取。中央數(shù)據(jù)庫(kù)的使用減少了管理的代價(jià)，并為認(rèn)證提供一個(gè)公共和獨(dú)立的?"第三方?"?。例如?Kerberos?、?Sesame?、?IBM KryptoKnight?（憑證庫(kù)思想?)?等。?Kerberos是由麻省理工大學(xué)發(fā)明的安全認(rèn)證服務(wù)，已經(jīng)被?UNIX?和?Windows?作為默認(rèn)的安全認(rèn)證服務(wù)集成進(jìn)操作系統(tǒng)。

3、???Agent-based?（基于代理人）

在這種解決方案中，有一個(gè)自動(dòng)地為不同的應(yīng)用程序認(rèn)證用戶身份的代理程序。這個(gè)代理程序需要設(shè)計(jì)有不同的功能。比如，它可以使用口令表或加密密鑰來自動(dòng)地將認(rèn)證的負(fù)擔(dān)從用戶移開。代理人被放在服務(wù)器上面，在服務(wù)器的認(rèn)證系統(tǒng)和客戶端認(rèn)證方法之間充當(dāng)一個(gè)?"?翻譯?"。例如?SSH?等。

4、???Token-based

例如?SecureID,WebID?，現(xiàn)在被廣泛使用的口令認(rèn)證，比如?FTP?、郵件服務(wù)器的登錄認(rèn)證，這是一種簡(jiǎn)單易用的方式，實(shí)現(xiàn)一個(gè)口令在多種應(yīng)用當(dāng)中使用。

5、???基于網(wǎng)關(guān)

6、???基于?SAML

SAML(Security Assertion Markup Language?，安全斷言標(biāo)記語言）的出現(xiàn)大大簡(jiǎn)化了?SSO?，并被?OASIS?批準(zhǔn)為?SSO?的執(zhí)行標(biāo)準(zhǔn)?。開源組織?OpenSAML?實(shí)現(xiàn)了?SAML?規(guī)范。

?

3.??????CAS?的基本原理

3.1.??結(jié)構(gòu)體系

從結(jié)構(gòu)體系看，?CAS?包括兩部分：?CAS Server?和?CAS Client?。

3.1.1.??????CAS Server

CAS Server?負(fù)責(zé)完成對(duì)用戶的認(rèn)證工作?,?需要獨(dú)立部署?,?CAS Server?會(huì)處理用戶名?/?密碼等憑證(Credentials)?。

3.1.2.??????CAS Client

負(fù)責(zé)處理對(duì)客戶端受保護(hù)資源的訪問請(qǐng)求，需要對(duì)請(qǐng)求方進(jìn)行身份認(rèn)證時(shí)，重定向到?CAS Server?進(jìn)行認(rèn)證。（原則上，客戶端應(yīng)用不再接受任何的用戶名密碼等?Credentials?）。

CAS Client?與受保護(hù)的客戶端應(yīng)用部署在一起，以?Filter?方式保護(hù)受保護(hù)的資源。

3.2.??CAS?原理和協(xié)議

3.2.1.??????基礎(chǔ)模式

基礎(chǔ)模式?SSO?訪問流程主要有以下步驟：

1.?訪問服務(wù)：?SSO?客戶端發(fā)送請(qǐng)求訪問應(yīng)用系統(tǒng)提供的服務(wù)資源。

2.?定向認(rèn)證：?SSO?客戶端會(huì)重定向用戶請(qǐng)求到?SSO?服務(wù)器。

3.?用戶認(rèn)證：用戶身份認(rèn)證。

4.?發(fā)放票據(jù)：?SSO?服務(wù)器會(huì)產(chǎn)生一個(gè)隨機(jī)的?Service Ticket?。

5.?驗(yàn)證票據(jù)：?SSO?服務(wù)器驗(yàn)證票據(jù)?Service Ticket?的合法性，驗(yàn)證通過后，允許客戶端訪問服務(wù)。

6.?傳輸用戶信息：?SSO?服務(wù)器驗(yàn)證票據(jù)通過后，傳輸用戶認(rèn)證結(jié)果信息給客戶端。

下面是?CAS?最基本的協(xié)議過程：

??

基礎(chǔ)協(xié)議圖

?

如上圖：?CAS Client?與受保護(hù)的客戶端應(yīng)用部署在一起，以?Filter?方式保護(hù)?Web?應(yīng)用的受保護(hù)資源，過濾從客戶端過來的每一個(gè)?Web?請(qǐng)求，同時(shí)，?CAS Client?會(huì)分析?HTTP?請(qǐng)求中是否包含請(qǐng)求?Service Ticket( ST?上圖中的?Ticket)?，如果沒有，則說明該用戶是沒有經(jīng)過認(rèn)證的；于是?CAS Client?會(huì)重定向用戶請(qǐng)求到?CAS Server?（?Step 2?），并傳遞?Service?（要訪問的目的資源地址）。?Step 3?是用戶認(rèn)證過程，如果用戶提供了正確的?Credentials?，?CAS Server?隨機(jī)產(chǎn)生一個(gè)相當(dāng)長(zhǎng)度、唯一、不可偽造的?Service Ticket?，并緩存以待將來驗(yàn)證，并且重定向用戶到?Service?所在地址（附帶剛才產(chǎn)生的?Service Ticket?）?,?并為客戶端瀏覽器設(shè)置一個(gè)?Ticket Granted Cookie?（?TGC?）?；?CAS Client在拿到?Service?和新產(chǎn)生的?Ticket?過后，在?Step 5?和?Step6?中與?CAS Server?進(jìn)行身份核實(shí)，以確保?Service Ticket?的合法性。

在該協(xié)議中，所有與?CAS Server?的交互均采用?SSL?協(xié)議，以確保?ST?和?TGC?的安全性。協(xié)議工作過程中會(huì)有?2?次重定向?的過程。但是?CAS Client?與?CAS Server?之間進(jìn)行?Ticket?驗(yàn)證的過程對(duì)于用戶是透明的（使用?HttpsURLConnection?）。

????CAS?請(qǐng)求認(rèn)證時(shí)序圖如下：

??

3.2.1.??????CAS?如何實(shí)現(xiàn)?SSO

當(dāng)用戶訪問另一個(gè)應(yīng)用的服務(wù)再次被重定向到?CAS Server?的時(shí)候，?CAS Server?會(huì)主動(dòng)獲到這個(gè)?TGC cookie?，然后做下面的事情：

1)?如果?User?持有?TGC?且其還沒失效，那么就走基礎(chǔ)協(xié)議圖的?Step4?，達(dá)到了?SSO?的效果；

2)?如果?TGC?失效，那么用戶還是要重新認(rèn)證?(?走基礎(chǔ)協(xié)議圖的?Step3)?。

?

3.2.2.??????CAS?代理模式

該模式形式為用戶訪問?App1?，?App1?又依賴于?App2?來獲取一些信息，如：?User -->App1 -->App2?。

這種情況下，假設(shè)?App2?也是需要對(duì)?User?進(jìn)行身份驗(yàn)證才能訪問，那么，為了不影響用戶體驗(yàn)（過多的重定向?qū)е?User?的?IE?窗口不停地閃動(dòng)?)?，?CAS?引入了一種?Proxy?認(rèn)證機(jī)制，即?CAS Client?可以代理用戶去訪問其它?Web?應(yīng)用。

代理的前提是需要?CAS Client?擁有用戶的身份信息?(?類似憑據(jù)?)?。之前我們提到的?TGC?是用戶持有對(duì)自己身份信息的一種憑據(jù)，這里的?PGT?就是?CAS Client?端持有的對(duì)用戶身份信息的一種憑據(jù)。憑借TGC?，?User?可以免去輸入密碼以獲取訪問其它服務(wù)的?Service Ticket?，所以，這里憑借?PGT?，?Web應(yīng)用可以代理用戶去實(shí)現(xiàn)后端的認(rèn)證，而?無需前端用戶的參與?。

下面為代理應(yīng)用（?helloService?）獲取?PGT?的過程：?（注：?PGTURL?用于表示一個(gè)?Proxy?服務(wù)，是一個(gè)回調(diào)鏈接；?PGT?相當(dāng)于代理證；?PGTIOU?為取代理證的鑰匙，用來與?PGT?做關(guān)聯(lián)關(guān)系；）

?

如上面的?CAS Proxy?圖所示，?CAS Client?在基礎(chǔ)協(xié)議之上，在驗(yàn)證?ST?時(shí)提供了一個(gè)額外的PGT URL(?而且是?SSL?的入口?)?給?CAS Server?，使得?CAS Server?可以通過?PGT URL?提供一個(gè)?PGT?給?CAS Client?。

CAS Client?拿到了?PGT(PGTIOU-85?…?..ti2td)?，就可以通過?PGT?向后端?Web?應(yīng)用進(jìn)行認(rèn)證。

下面是代理認(rèn)證和提供服務(wù)的過程：

?

如上圖所示，?Proxy?認(rèn)證與普通的認(rèn)證其實(shí)差別不大，?Step1?，?2?與基礎(chǔ)模式的?Step1,2?幾乎一樣，唯一不同的是，?Proxy?模式用的是?PGT?而不是?TGC?，是?Proxy Ticket?（?PT?）而不是?Service Ticket?。

?

3.2.3.??????輔助說明

CAS?的?SSO?實(shí)現(xiàn)方式可簡(jiǎn)化理解為：?1?個(gè)?Cookie?和?N?個(gè)?Session?。?CAS Server?創(chuàng)建?cookie，在所有應(yīng)用認(rèn)證時(shí)使用，各應(yīng)用通過創(chuàng)建各自的?Session?來標(biāo)識(shí)用戶是否已登錄。

用戶在一個(gè)應(yīng)用驗(yàn)證通過后，以后用戶在同一瀏覽器里訪問此應(yīng)用時(shí)，客戶端應(yīng)用中的過濾器會(huì)在?session?里讀取到用戶信息，所以就不會(huì)去?CAS Server?認(rèn)證。如果在此瀏覽器里訪問別的?web?應(yīng)用時(shí)，客戶端應(yīng)用中的過濾器在?session?里讀取不到用戶信息，就會(huì)去?CAS Server?的?login?接口認(rèn)證，但這時(shí)CAS Server?會(huì)讀取到瀏覽器傳來的?cookie?（?TGC?），所以?CAS Server?不會(huì)要求用戶去登錄頁(yè)面登錄，只是會(huì)根據(jù)?service?參數(shù)生成一個(gè)?Ticket?，然后再和?web?應(yīng)用做一個(gè)驗(yàn)證?ticket?的交互而已。

3.3 ?術(shù)語解釋

3.3.1

CAS的核心就是其Ticket，及其在Ticket之上的一系列處理操作。CAS的主要票據(jù)有TGT、ST、PGT、PGTIOU、PT，其中TGT、ST是CAS1.0協(xié)議中就有的票據(jù)，PGT、PGTIOU、PT是CAS2.0協(xié)議中有的票據(jù)。

• TGT（Ticket Grangting Ticket）

TGT是CAS為用戶簽發(fā)的登錄票據(jù)，擁有了TGT，用戶就可以證明自己在CAS成功登錄過。TGT封裝了Cookie值以及此Cookie值對(duì)應(yīng)的用戶信息。用戶在CAS認(rèn)證成功后，CAS生成cookie（叫TGC），寫入瀏覽器，同時(shí)生成一個(gè)TGT對(duì)象，放入自己的緩存，TGT對(duì)象的ID就是cookie的值。當(dāng)HTTP再次請(qǐng)求到來時(shí)，如果傳過來的有CAS生成的cookie，則CAS以此cookie值為key查詢緩存中有無TGT?，如果有的話，則說明用戶之前登錄過，如果沒有，則用戶需要重新登錄。

• TGC?（Ticket-granting cookie）：

存放用戶身份認(rèn)證憑證的cookie，在瀏覽器和CAS Server間通訊時(shí)使用，并且只能基于安全通道傳輸（Https），是CAS Server用來明確用戶身份的憑證。

• ST（Service Ticket）

ST是CAS為用戶簽發(fā)的訪問某一service的票據(jù)。用戶訪問service時(shí)，service發(fā)現(xiàn)用戶沒有ST，則要求用戶去CAS獲取ST。用戶向CAS發(fā)出獲取ST的請(qǐng)求，如果用戶的請(qǐng)求中包含cookie，則CAS會(huì)以此cookie值為key查詢緩存中有無TGT，如果存在TGT，則用此TGT簽發(fā)一個(gè)ST，返回給用戶。用戶憑借ST去訪問service，service拿ST去CAS驗(yàn)證，驗(yàn)證通過后，允許用戶訪問資源。

• PGT（Proxy Granting Ticket）

Proxy Service的代理憑據(jù)。用戶通過CAS成功登錄某一Proxy Service后，CAS生成一個(gè)PGT對(duì)象，緩存在CAS本地，同時(shí)將PGT的值（一個(gè)UUID字符串）回傳給Proxy Service，并保存在Proxy Service里。Proxy Service拿到PGT后，就可以為Target Service（back-end service）做代理，為其申請(qǐng)PT。

• PGTIOU（全稱?Proxy Granting Ticket I Owe You）

PGTIOU是CAS協(xié)議中定義的一種附加票據(jù)，它增強(qiáng)了傳輸、獲取PGT的安全性。
PGT的傳輸與獲取的過程：Proxy Service調(diào)用CAS的serviceValidate接口驗(yàn)證ST成功后，CAS首先會(huì)訪問pgtUrl指向的https url，將生成的?PGT及PGTIOU傳輸給proxy service，proxy service會(huì)以PGTIOU為key，PGT為value，將其存儲(chǔ)在Map中；然后CAS會(huì)生成驗(yàn)證ST成功的xml消息，返回給Proxy Service，xml消息中含有PGTIOU，proxy service收到Xml消息后，會(huì)從中解析出PGTIOU的值，然后以其為key，在map中找出PGT的值，賦值給代表用戶信息的Assertion對(duì)象的pgtId，同時(shí)在map中將其刪除。

• PT（Proxy Ticket）

PT是用戶訪問Target Service（back-end service）的票據(jù)。如果用戶訪問的是一個(gè)Web應(yīng)用，則Web應(yīng)用會(huì)要求瀏覽器提供ST，瀏覽器就會(huì)用cookie去CAS獲取一個(gè)ST，然后就可以訪問這個(gè)Web應(yīng)用了。如果用戶訪問的不是一個(gè)Web應(yīng)用，而是一個(gè)C/S結(jié)構(gòu)的應(yīng)用，因?yàn)镃/S結(jié)構(gòu)的應(yīng)用得不到cookie，所以用戶不能自己去CAS獲取ST，而是通過訪問proxy service的接口，憑借proxy service的PGT去獲取一個(gè)PT，然后才能訪問到此應(yīng)用。?

3.3.2、TGT、ST、PGT、PT之間關(guān)系

???????1）ST是TGT簽發(fā)的。用戶在CAS上認(rèn)證成功后，CAS生成TGT，用TGT簽發(fā)一個(gè)ST，ST的ticketGrantingTicket屬性值是TGT對(duì)象，然后把ST的值redirect到客戶應(yīng)用。

??? 2）PGT是ST簽發(fā)的。用戶憑借ST去訪問Proxy service，Proxy service去CAS驗(yàn)證ST（同時(shí)傳遞PgtUrl參數(shù)給CAS），如果ST驗(yàn)證成功，則CAS用ST簽發(fā)一個(gè)PGT，PGT對(duì)象里的ticketGrantingTicket是簽發(fā)ST的TGT對(duì)象。

??? 3）PT是PGT簽發(fā)的。Proxy service代理back-end service去CAS獲取PT的時(shí)候，CAS根據(jù)傳來的pgt參數(shù)，獲取到PGT對(duì)象，然后調(diào)用其grantServiceTicket方法，生成一個(gè)PT對(duì)象。

?

其它說明如下：

• Ticket Granting ticket(TGT)?：票據(jù)授權(quán)票據(jù)，由?KDC?的?AS?發(fā)放。即獲取這樣一張票據(jù)后，以后申請(qǐng)各種其他服務(wù)票據(jù)?(ST)?便不必再向?KDC?提交身份認(rèn)證信息?(Credentials)?；
• Authentication service(AS) ---------?認(rèn)證用服務(wù)，索取?Credentials?，發(fā)放?TGT?；
• Ticket-granting service (TGS) ---------?票據(jù)授權(quán)服務(wù)，索取?TGT?，發(fā)放?ST?；
• KDC( Key Distribution Center ) ----------?密鑰發(fā)放中心；

?

4.??????CAS?安全性

CAS?的安全性僅僅依賴于?SSL?。使用的是?secure cookie?。

4.1.??TGC/PGT?安全性

對(duì)于一個(gè)?CAS?用戶來說，最重要是要保護(hù)它的?TGC?，如果?TGC?不慎被?CAS Server?以外的實(shí)體獲得，?Hacker?能夠找到該?TGC?，然后冒充?CAS?用戶訪問?所有?授權(quán)資源。?PGT?的角色跟?TGC?是一樣的。

從基礎(chǔ)模式可以看出，?TGC?是?CAS Server?通過?SSL?方式發(fā)送給終端用戶，因此，要截取?TGC?難度非常大，從而確保?CAS?的安全性。

TGT?的存活周期默認(rèn)為?120?分鐘。

4.2.??ST/PT?安全性

ST?（?Service Ticket?）是通過?Http?傳送的，因此網(wǎng)絡(luò)中的其他人可以?Sniffer?到其他人的?Ticket?。?CAS?通過以下幾方面來使?ST?變得更加安全（事實(shí)上都是可以配置的）：

1、???ST?只能使用一次

CAS?協(xié)議規(guī)定，無論?Service Ticket?驗(yàn)證是否成功，?CAS Server?都會(huì)清除服務(wù)端緩存中的該Ticket?，從而可以確保一個(gè)?Service Ticket?不被使用兩次。

2、???ST?在一段時(shí)間內(nèi)失效

CAS?規(guī)定?ST?只能存活一定的時(shí)間，然后?CAS Server?會(huì)讓它失效。默認(rèn)有效時(shí)間為?5?分鐘。

3、???ST?是基于隨機(jī)數(shù)生成的

ST?必須足夠隨機(jī)，如果?ST?生成規(guī)則被猜出，?Hacker?就等于繞過?CAS?認(rèn)證，直接訪問?對(duì)應(yīng)的服務(wù)。

?

5.??????參考資料

1、?https://wiki.jasig.org/display/CASUM/Introduction

2、?http://www.jasig.org/cas/protocol/

3、?http://www.ibm.com/developerworks/cn/opensource/os-cn-cas/index.html

4、?http://www.blogjava.net/security/archive/2006/10/02/sso_in_action.html

5、?http://baike.baidu.com/view/190743.htm

6、http://www.coin163.com/java/cas/cas.html

轉(zhuǎn)載于:https://www.cnblogs.com/prctice/p/5772701.html

總結(jié)

以上是生活随笔為你收集整理的分析单点登录cas的解决方式的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。