1.      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等。

2.      SSO單點登入原理

本文內容主要針對Web SSO。

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

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

1、 User（多個）

2、 Web應用（多個）

3、 SSO認證中心（1個）

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

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

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

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

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的基本原理

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

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

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

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

基礎模式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請求認證時序圖如下：

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

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

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

該模式形式為使用者訪問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。

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的互動而已。

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。

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

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

TGT的存活週期預設為120分鐘。

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

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