開放源碼的ＣＡＳ單點登錄系統研究

〔摘 要〕單點登錄是解決網絡環境下應用集成和門戶系統安全認證的一種有效策略，CAS是Yale大學開發的一種開放源碼單點登錄系統。本文簡要介紹了CAS的一些優點，從體系結構、認證模式等方面對CAS做了深入分析，并探討了CAS在數字圖書館中的應用前景。

〔關鍵詞〕單點登錄；CAS；開放源碼軟件；數字圖書館

〔中圖分類號〕G350 〔文獻標識碼〕A 〔文章編號〕1008-0821(2009)03-0125-03

單點登錄(Single Sign-On，簡稱SSO)是Web應用環境中實現用戶統一身份認證的重要組成部分。隨著數字圖書館應用系統的整合以及門戶應用的發展，單點登錄已經成為人們關注和研究的熱點之一。基于開放源碼軟件的數字圖書館建設是數字圖書館發展的重要趨勢[1]，目前單點登錄的開放源碼軟件已經有多個，如SUN支持的OpenSSO項目[2]、JOSSO軟件[3]、美國Internet2高級網絡聯盟(MACE)小組開發的Shibboleth系統[4]以及Yale大學發起的CAS項目[5]等。

其中，Yale CAS以其合理的體系結構、方便的配置管理、成熟的技術等特點，得到了廣泛應用[6]，并成為JA-SIG的一個正式項目。本文主要從體系結構、認證模式等方面深入分析了CAS，并探討了其在數字圖書館中的應用前景。

1 CAS優點

(1)配置簡單:CAS Server基于Spring Framework編寫，對其管理，大多只需通過配置Java Bean XML即可；

(2)支持多種認證接口:CAS Server提供了一套易于定制的用戶認證器接口，不論是傳統的用戶名/密碼方式、還是采用LDAP服務器，都可以通過對驗證器模板稍加修改，便可使用；

(3)松散耦合:CAS被設計成可獨立部署的B/S Web應用，Server與Client分開實現，降低了認證模塊與應用系統的耦合度，提供了更好的SOA設計和更彈性的安全策略；

(4)多語言支持:CAS Client支持多種語言的客戶端，如Java、.NET、PHP、Perl、Ruby等；

(5)安全性高:在CAS協議中，所有與CAS的交互均采用SSL協議，保證了系統安全性；

(6)支持復雜環境應用:CAS 2.0協議擴展了Proxy(代理)認證，Web應用可作為代理，訪問其它的Web應用，從而使CAS可支持更高級、更復雜的應用場景。

2 CAS體系結構

2.1 技術框架

CAS在結構上被設計成兩個部分:CAS Server和CAS Client。

CAS Server是一個單獨部署的Web應用，負責用戶身份認證工作，它的實現是運行在HTTPS服務器上的幾個Java Servlet，通過3個URL來訪問:Login URL、Validation URL、Logout URL。目前，CAS Server是基于Spring Framework編寫的，大大提高了服務器端的配置管理效率；另外，CAS Server還提供了一套易于定制的用戶認證器接口，使得CAS的認證方式與CAS協議分離，開發者可根據自身需要，來訂制或擴展自己的認證邏輯；CAS Server甚至還提供了兩套默認系統界面供用戶選擇使用或擴展。

CAS Client負責本地Web應用的受保護資源的訪問請求。用戶需要登錄時，CAS Client將其請求重定向到CAS Server進行認證，而本地Web應用不再接受任何的用戶名/密碼或其他類似的憑證(Credentials)。CAS Client與Web應用部署在一起，以Filter方式保護受保護的資源。對于每一個對受保護資源的Web請求，CAS Client會分析該請求中是否包含ST(Service Ticket)，只有包含ST的請求才被認為是已經登錄的用戶，如果不包含ST，則將該請求重定向到CAS Server。

2.2 服務角色

在CAS的服務架構中，設計了4種服務角色[7]:CAS(用戶身份提供者)、Service(服務提供者)、Proxy(代理)、Target(目標服務)。

CAS:用戶身份提供者，由CAS Server扮演，主要作用是對登錄用戶的身份進行認證，以判斷其是否可信賴用戶；Service:服務提供者，是通過CAS對用戶進行認證，并為用戶提供某項服務的一個Web應用；Proxy:是代理指定用戶訪問其它服務的一個服務；Target:也叫后端服務(back-end service)，是承認代理憑證的某個指定的服務。

在實際應用環境中，一個Web應用有時可能同時扮演多個服務角色。例如，當用戶登錄門戶，通過門戶向郵件服務器請求電子郵件。在這個過程中，門戶和郵件系統都需要向CAS認證用戶，同時門戶系統還需要代理用戶向CAS Server獲取訪問郵件服務器的代理憑證。因而，門戶就充當了Service和Proxy的雙重角色。

2.3 憑證類型

在CAS系統中，各方通過憑證(Ticket)對用戶身份進行驗證。CAS系統中設計了5種憑證[7]:TGC、ST、PGT、PGTIOU、PT。

TGC(Ticket-Granting Cookie):存放用戶身份認證憑證的cookie，在瀏覽器和CAS間通訊時使用，并且只能基于安全通道傳輸，是CAS用來明確用戶身份的憑證；ST(Service Ticket):服務的惟一標識碼。由CAS Server發出，通過客戶端瀏覽器到達業務服務器端。一個特定的服務只能有一個惟一的ST；PGT(Proxy-Granting ticket):由CAS Server頒發給擁有ST憑證的服務。PGT綁定一個用戶的特定服務，使其擁有向CAS Server申請，獲得PT的能力；PGTIOU(Proxy-Granting Ticket IOU):作用是將通過憑證校驗時的應答信息由CAS Server返回給CAS Client，同時，與該GTIOU對應的PGT將通過回調鏈接傳給Web應用。Web應用負責維護PGTIOU與PGT之間映射關系的內容表；PT(Proxy Ticket):是應用程序代理用戶身份對目標程序進行訪問的憑證。PT保存有代理及代理們進行逐級訪問過程的信息。

3 認證模式

從Web應用環境的復雜程度劃分，CAS的認證模式可分為基礎認證模式和代理認證模式，其中基礎認證模式一般可滿足大部分簡單的單點登錄應用，而代理認證模式可適應復雜環境下的單點登錄認證。

3.1 基礎模式

圖1說明了CAS的基本認證過程。在該圖中，當用戶首次請求http:∥webapp應用時，由于沒有登錄，CAS Client將該請求重定向到CAS Server，并傳遞Service(即要訪問的目的地址)，以便登錄成功后轉回該地址；用戶輸入認證信息，CAS Server進行認證，如果認證成功，CAS Server隨機產生一個相當長度、惟一、不可偽造的ST，之后重定向到Service所在地址，并為客戶端瀏覽器設置一個TGC(Ticket Granted Cookie)，CAS Client在拿到service和新產生的ticket后，向CAS Server進行身份核實，以保證ST的合法性。

在整個過程中，所有與CAS的交互均采用SSL協議，以確保ST和TGC的安全；另外，CAS雖然會有兩次重定向，但CAS Client與CAS Server的ticket驗證，對于用戶來說是透明的。

3.2 代理模式

CAS 2.0擴展了Proxy認證功能，即CAS Client可以代理用戶去訪問其他Web應用。通過代理認證功能，CAS可以適應更復雜的Web應用環境。圖2簡單示意了CAS的Proxy認證過程。

在該圖中，用戶訪問Web應用1(http:∥webapp1)，而Web應用1又依賴Web應用2(http:∥webapp2)來獲取數據，并且Web應用2也是需要進行身份認證才能訪問。

當用戶請求Web應用1時，同基礎模式一樣，CAS Client將該請求重定向到CAS Server。不同于基礎模式的是:代理模式使用PGT，而不是TGC；CAS Server傳回PT，而不是ST。PGT與TGC不同，TGC是用戶持有的對自己身份信息的一種憑證，PGT是CAS Client持有的對用戶身份的一種憑據。用戶使用TGC獲取其他服務的ST，而Web應用使用PGT代理用戶去實現后端的認證，而無需前端用戶的參與。通過PT，Web應用2知道Web應用1代理的用戶是誰。根據本地策略，Web應用2有義務為PGTURL=http:∥webapp1/proxy提供服務(PGTURL是一個Proxy服務)，于是它傳遞數據給Web應用1。

在這個過程中，Web應用1扮演著Service和Proxy的雙重角色，協助用戶從Web應用2返回所需數據，而Web應用2是一個Target。

4 CAS在數字圖書館的應用分析

基于開放源碼軟件的開發與利用已經成為我國數字圖書館建設中的一個重要方面。開放源碼軟件不僅解決了某些圖書館所面臨的技術問題和資金問題，而且提高了我國數字圖書館系統建設的層次和起點，對加快我國數字圖書館的發展有著重要意義。作為一個開放源碼的單點登錄系統，CAS配置方便、實用有效、足夠安全，在圖書館的應用系統整合、門戶建設中，有著良好的應用前景。

CAS應用于數字圖書館建設，最常見的可有以下兩種模式:

4.1 圖書館作為CAS中的用戶身份提供者

在這種模式中，CAS部署在圖書館應用環境中，作為圖書館的一項應用服務存在，負責用戶的認證工作。對于一個獨立的圖書館來說，這是一種基本的應用模式。對于機構內部的圖書館，如果需要針對用戶提供特殊服務，也可適用于這種模式。例如，大學圖書館提供網上預約、續借、館際互借、MyLibrary個性化服務等，就需要在圖書館內部部署CAS Server，為這些服務或應用提供用戶認證和授權。在這種模式中，圖書館所面臨的主要問題是如何管理大量的用戶信息，如用戶信息的存儲、備份、安全、同步等問題。

在CAS中，提供了多種用戶認證接口，如用戶名/密碼方式、基于數據庫或XML文件檢索方式、LDAP等，CAS采用哪種方式認證與基本協議是分離的，數字圖書館開發人員可以根據認證的接口定制或擴展。

4.2 圖書館Web應用作為CAS系統的Service

對于機構內部的圖書館，這種模式較為常見。例如，目前，許多高校已在校園網實現了“一卡通”，即學生在校園網內只使用一種身份，便可通行于校園網內各Web系統。如果在校園網部署了CAS系統，圖書館的各種服務，如個性化服務等，可作為CAS系統的客戶端，與校園網內已有的CAS系統一起為用戶提供透明的服務。

在這種模式中，用戶的身份鑒定工作由校園網的CAS Server完成，圖書館需要在本地Web應用中配置CAS Client，所要解決的主要問題是如何定義用戶的屬性和權利，例如，哪些資源是匿名用戶可以訪問的，哪些資源是需要用戶登錄之后才能訪問的。

參考文獻

[1]張智雄.開放源碼軟件——全球數字圖書館研究與建設的重要活動和實踐[J].數字圖書館論壇，2006，(增):1-11.

[2]OpenSSO[EB/OL].https:∥opensso.dev.java.net，2008-08-02.

[3]JOSSO—Java Open Single Sign-On Project Home[EB/OL].http:∥www.josso.org/confluence/display/JOSSO1/JOSSO++Java+Open+Single+SignOn+Project+Home，2008-08-02.

[4]Shibboleth[EB/OL].http:∥shibboleth.internet2.edu，2008-08-03.

[5]Central Authentication Service[EB/OL].http:∥www.ja-sig.org/products/cas，2008-08-01.

[6]Deployers[EB/OL].http:∥www.ja-sig.org/products/cas/community/deployers/index.html，2008-08-05.

[7]CAS 2 Architecture[EB/OL].http:∥www.ja-sig.org/products/cas/overview/cas2architecture/index.html，2008-08-10.