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ù)庫的使用減少了管理的代價(jià)，并為認(rèn)證提供一個(gè)公共和獨(dú)立的?"第三方?"?。例如?Kerberos?、?Sesame?、?IBM KryptoKnight?（憑證庫思想?)?等。?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ì)要求用戶去登錄頁面登錄，只是會(huì)根據(jù)?service?參數(shù)生成一個(gè)?Ticket?，然后再和?web?應(yīng)用做一個(gè)驗(yàn)證?ticket?的交互而已。

3.3.??術(shù)語解釋

CAS?系統(tǒng)中設(shè)計(jì)了?5?中票據(jù)：?TGC?、?ST?、?PGT?、?PGTIOU?、?PT?。

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

????Service ticket(ST)?：服務(wù)票據(jù)，服務(wù)的惟一標(biāo)識(shí)碼?,?由?CAS Server?發(fā)出（?Http?傳送），通過客戶端瀏覽器到達(dá)業(yè)務(wù)服務(wù)器端；一個(gè)特定的服務(wù)只能有一個(gè)惟一的?ST?；

????Proxy-Granting ticket?（?PGT?）：由?CAS Server?頒發(fā)給擁有?ST?憑證的服務(wù)，?PGT?綁定一個(gè)用戶的特定服務(wù)，使其擁有向?CAS Server?申請(qǐng)，獲得?PT?的能力；

????Proxy-Granting Ticket I Owe You?（?PGTIOU?）?:?作用是將通過憑證校驗(yàn)時(shí)的應(yīng)答信息由?CAS Server?返回給?CAS Client?，同時(shí)，與該?PGTIOU?對(duì)應(yīng)的?PGT?將通過回調(diào)鏈接傳給?Web?應(yīng)用。?Web?應(yīng)用負(fù)責(zé)維護(hù)?PGTIOU?與?PGT?之間映射關(guān)系的內(nèi)容表；

????Proxy Ticket (PT)?：是應(yīng)用程序代理用戶身份對(duì)目標(biāo)程序進(jìn)行訪問的憑證；

?

其它說明如下：

????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

總結(jié)

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

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