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