CAS實現SSO單點登錄原理

1.CAS簡介

1.1.What is CAS？

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