Android教程網
  1. 首頁
  2. Android 技術
  3. Android 手機
  4. Android 系統教程
  5. Android 游戲
 Android教程網 >> Android技術 >> Android開發 >> 關於android開發 >> CAS實現SSO單點登錄原理

CAS實現SSO單點登錄原理

編輯:關於android開發

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基礎協議圖

基礎協議圖

如上圖: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認證時序圖

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代理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

  1. 上一頁:
  2. 下一頁:
熱門文章
閱讀排行版
Copyright © Android教程網 All Rights Reserved