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

CAS?開始于?2001?年， 并在?2004?年?12?月正式成為?JA-SIG?的一個項目。

1.2.??主要特性

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

?

2.??????SSO?單點登錄原理

本文內容主要針對?Web SSO?。

2.1.??什么是SSO

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

2.2.??SSO?原理

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

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

1、?User?（多個）

2、?Web?應用（多個）

3、?SSO?認證中心（?1?個?）

2.2.2.??????SSO?實現模式的原則

SSO?實現模式一般包括以下三個原則：

1、???所有的認證登錄都在?SSO?認證中心進行；

2、???SSO?認證中心通過一些方法來告訴?Web?應用當前訪問用戶究竟是不是已通過認證的用戶；

3、???SSO?認證中心和所有的?Web?應用建立一種信任關系，也就是說?web?應用必須信任認證中心。（單點信任）

2.2.3.??????SSO?主要實現方式

SSO?的主要實現方式有：

1、???共享?cookies

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

缺點：不靈活而且有不少安全隱患，已經被拋棄。

2、???Broker-based(?基于經紀人?)

這種技術的特點就是，有一個集中的認證和用戶帳號管理的服務器。經紀人給被用于進一步請求的電子身份存取。中央數據庫的使用減少了管理的代價，并為認證提供一個公共和獨立的?"第三方?"?。例如?Kerberos?、?Sesame?、?IBM KryptoKnight?（憑證庫思想?)?等。?Kerberos是由麻省理工大學發明的安全認證服務，已經被?UNIX?和?Windows?作為默認的安全認證服務集成進操作系統。

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

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

4、???Token-based

例如?SecureID,WebID?，現在被廣泛使用的口令認證，比如?FTP?、郵件服務器的登錄認證，這是一種簡單易用的方式，實現一個口令在多種應用當中使用。

5、???基于網關

6、???基于?SAML

SAML(Security Assertion Markup Language?，安全斷言標記語言）的出現大大簡化了?SSO?，并被?OASIS?批準為?SSO?的執行標準?。開源組織?OpenSAML?實現了?SAML?規范。

?

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

3.1.??結構體系

從結構體系看，?CAS?包括兩部分：?CAS Server?和?CAS Client?。

3.1.1.??????CAS Server

CAS Server?負責完成對用戶的認證工作?,?需要獨立部署?,?CAS Server?會處理用戶名?/?密碼等憑證(Credentials)?。

3.1.2.??????CAS Client

負責處理對客戶端受保護資源的訪問請求，需要對請求方進行身份認證時，重定向到?CAS Server?進行認證。（原則上，客戶端應用不再接受任何的用戶名密碼等?Credentials?）。

CAS Client?與受保護的客戶端應用部署在一起，以?Filter?方式保護受保護的資源。

3.2.??CAS?原理和協議

3.2.1.??????基礎模式

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

1.?訪問服務：?SSO?客戶端發送請求訪問應用系統提供的服務資源。

2.?定向認證：?SSO?客戶端會重定向用戶請求到?SSO?服務器。

3.?用戶認證：用戶身份認證。

4.?發放票據：?SSO?服務器會產生一個隨機的?Service Ticket?。

5.?驗證票據：?SSO?服務器驗證票據?Service Ticket?的合法性，驗證通過后，允許客戶端訪問服務。

6.?傳輸用戶信息：?SSO?服務器驗證票據通過后，傳輸用戶認證結果信息給客戶端。

下面是?CAS?最基本的協議過程：

?

基礎協議圖

?

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

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

????CAS?請求認證時序圖如下：

??

3.2.1.??????CAS?如何實現?SSO

當用戶訪問另一個應用的服務再次被重定向到?CAS Server?的時候，?CAS Server?會主動獲到這個?TGC cookie?，然后做下面的事情：

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

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

?

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

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

這種情況下，假設?App2?也是需要對?User?進行身份驗證才能訪問，那么，為了不影響用戶體驗（過多的重定向導致?User?的?IE?窗口不停地閃動?)?，?CAS?引入了一種?Proxy?認證機制，即?CAS Client?可以代理用戶去訪問其它?Web?應用。

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

下面為代理應用（?helloService?）獲取?PGT?的過程：?（注：?PGTURL?用于表示一個?Proxy?服務，是一個回調鏈接；?PGT?相當于代理證；?PGTIOU?為取代理證的鑰匙，用來與?PGT?做關聯關系；）

??

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

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

下面是代理認證和提供服務的過程：

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

?

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

CAS?的?SSO?實現方式可簡化理解為：?1?個?Cookie?和?N?個?Session?。?CAS Server?創建?cookie，在所有應用認證時使用，各應用通過創建各自的?Session?來標識用戶是否已登錄。

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

3.3.??術語解釋

CAS?系統中設計了?5?中票據：?TGC?、?ST?、?PGT?、?PGTIOU?、?PT?。

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

????Service ticket(ST)?：服務票據，服務的惟一標識碼?,?由?CAS Server?發出（?Http?傳送），通過客戶端瀏覽器到達業務服務器端；一個特定的服務只能有一個惟一的?ST?；

????Proxy-Granting ticket?（?PGT?）：由?CAS Server?頒發給擁有?ST?憑證的服務，?PGT?綁定一個用戶的特定服務，使其擁有向?CAS Server?申請，獲得?PT?的能力；

????Proxy-Granting Ticket I Owe You?（?PGTIOU?）?:?作用是將通過憑證校驗時的應答信息由?CAS Server?返回給?CAS Client?，同時，與該?PGTIOU?對應的?PGT?將通過回調鏈接傳給?Web?應用。?Web?應用負責維護?PGTIOU?與?PGT?之間映射關系的內容表；

????Proxy Ticket (PT)?：是應用程序代理用戶身份對目標程序進行訪問的憑證；

?

其它說明如下：

????Ticket Granting ticket(TGT)?：票據授權票據，由?KDC?的?AS?發放。即獲取這樣一張票據后，以后申請各種其他服務票據?(ST)?便不必再向?KDC?提交身份認證信息?(Credentials)?；

????Authentication service(AS) ---------?認證用服務，索取?Credentials?，發放?TGT?；

????Ticket-granting service (TGS) ---------?票據授權服務，索取?TGT?，發放?ST?；

????KDC( Key Distribution Center ) ----------?密鑰發放中心；

?

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

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

4.1.??TGC/PGT?安全性

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

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

TGT?的存活周期默認為?120?分鐘。

4.2.??ST/PT?安全性

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?認證，直接訪問?對應的服務。

?

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

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。