一種基于單點登錄的實驗室統一身份認證方案

王 群，李馥娟

（江蘇警官學院 計算機信息與網絡安全系，江蘇 南京 210031）

隨著國家對新工科、新農科、新醫科、新文科建設力度的進一步加大，以及對“以本為本”教育理念的不斷推進，實驗教學在人才培養中的重要性得到進一步加強，實驗室已成為提升人才培養質量的強有力支撐，實驗室建設越來越引起各高校的普遍重視。從管理手段來看，涉及實驗室的資產管理、師生信息管理、實驗授權管理等已基本實現了網絡化[1]。然而，同一高校建設的不同實驗室之間普遍存在著相互之間孤立、信息無法共享、操作不便、管理分散等現象，嚴重影響了實驗室的使用效果和管理水平。

本文結合本單位實驗室建設與管理實際，采用基于單點登錄方式的統一身份認證技術，通過建設統一身份認證中心實現對所有用戶身份信息的認證，每一個用戶在成功登錄信任域內任何一個實驗系統后，便可以自由訪問其他授權系統而不需要再次輸入用戶名和密碼，實現了信息資源的共享，規范了管理，增強了實驗系統的安全性，提高了實驗室的使用效率和管理水平。

1 基于單點登錄的統一身份認證技術

1.1 統一身份認證

在信息化程度尚不發達的早期系統建設中，每個系統都在獨立維護著一套用戶身份認證機制，同一用戶在訪問不同的系統時需要分別輸入對應系統各自的用戶名和密碼，使用和管理極不方便。而且，用戶信息分散存放在不同的系統中，極易造成信息的泄露，安全隱患較大。

統一身份認證[2]通過在分布式環境中創建一個權威的認證中心，由認證中心統一接管原來分散在各系統上的身份認證模塊的功能，由位于認證中心的唯一用戶信息數據庫統一驗證用戶身份的真偽，涉及用戶身份的信息在存儲和交換過程中的安全問題全部由統一身份認證中心提供的安全協議和策略來保證。圖1所示是統一身份認證流程，具體描述為：①用戶在統一身份認證中心進行注冊，經管理員確認后成為合法用戶；②用戶登錄信任域內的某一授權應用系統；③應用系統將用戶訪問請求重定向到統一身份認證中心，用戶在彈出的身份認證界面中輸入用戶名和密碼等用戶身份信息憑據；④統一身份認證中心為該用戶創建一個票據（ticket），并將該票據返回用戶，同時頁面重定向到應用系統；⑤用戶將票據提交給應用系統；⑥應用系統將票據發給統一身份認證中心進行驗證；⑦統一身份認證服務器通過查詢用戶身份信息數據庫來判斷票據的有效性，并將驗證結果及相關用戶屬性返回給應用系統；⑧經過身份認證后，應用系統根據統一身份認證服務器的返回結果，執行后續的業務流程。

圖1 統一身份認證流程

從以上認證過程可以看出，所有信任域內集成的應用系統都以票據作為用戶身份的唯一憑證，向統一身份認證中心驗證用戶身份的真實性并獲取相應的屬性（如可授權訪問的資源）。票據是由統一身份認證中心根據用戶ID（用戶身份的唯一標識）以及請求報文中的相關信息和參數，按確定的算法生成并經統一身份認證中心簽名的一組字符串。這些字符串除由統一身份認證中心用于驗證用戶身份和授權外，沒有其他的意義，增加了認證過程的安全性。OpenID[3]是一個典型的統一身份認證架構，OAuth[4]安全架構提供了一個具有代表性的票據生成和管理模型，可供讀者進一步學習時參考。

1.2 單點登錄

在圖1 所示的統一身份認證過程中，只是強調由統一身份認證中心為每個應用系統集中提供身份的真實性和有效性驗證功能，同一用戶在成功登錄某一應用系統后，在票據的有效期內，如果還需要繼續訪問信任域內的其他應用系統，則不再需要重新進行登錄操作。

單點登錄（single sign-on，SSO）[5]的思想是在同一信任域內，當成功登錄其中一個應用系統后，在繼續訪問域中其他任何一個授權系統時，不再要求用戶再次輸入用戶名和密碼等用戶信息憑證，而所有的認證過程由系統自動完成。單點登錄的實現是在統一身份認證的基礎上，當用戶從統一身份認證中心獲得了票據后，在訪問其他的授權系統時，用戶先將訪問票據提交給要訪問的應用系統，應用系統再將該票據交由統一身份認證中心進行有效性驗證，并決定是否允許訪問。通常情況下，在用戶通過第一次認證后，生成的票據中會設置一個時間戳，如果用戶在規定的時間到期之前訪問其他的授權系統，都不會要求再次進行認證。目前主要的單點登錄解決方案和應用產品有：

（1）Cookies。Cookies 最早由Netscape 公司用于其Navigator 瀏覽器中，之后絕大多數瀏覽器開始支持Cookies。Cookies 是指在HTTP 協議下由服務器創建并發送給客戶端計算機的一個很小的純文本文件[6]，該文件中包含有用戶ID 和票據等信息，以此可以實現單點登錄過程中用戶的身份認證。基于Cookies 的單點登錄實現較為簡單，而且絕大多數計算機語言都支持Cookies 操作，但Cookies 僅適用于單一域內，無法直接進行跨域操作。同時，由于Cookies 文件在過期之前一直保存在客戶端，存在較大的安全隱患。

（2）SAML。SAML（security assertion markup language，安全斷言標記語言）[7]是一種在Web 應用環境下基于XML 語言的安全架構，其主要功能是在多信任域中交換用戶身份認證信息和資源授權信息。SAML 支持跨域操作及異構平臺之間的信息交換，可用于由多個信任域組成的大型網絡的身份認證。SAML 使用SSL/TLS 對信任站點之間交換的信息進行加密處理，使用安全令牌來避免重放攻擊，具有較高的安全性。

（3）CAS。CAS（central authentication service，中央認證服務）[8]是耶魯大學發起開發的一個用于為Web 應用系統提供單點登錄方法的開源項目，為企業間的協同操作提供獨立于平臺的、可擴展的平臺支撐。基于CAS 的單點登錄的實現流程較為簡單，對應用系統的授權管理較為方便。CAS 不但適用于Web 系統的認證，而且可以為僅支持Web 前端的非Web 應用提供單點登錄功能。CAS 可以與Cookies 配合使用，但與單純的基于Cookies 的單點登錄不同的是，在CAS中客戶端的Cookies 文件是經過加密處理的，安全性有了一定的提高。但由于用于驗證用戶身份的票據存放在Cookies 文件中，在一定程度上影響了應用的安全性。

（4）Passport。Passport 是微軟.NET 的有機組成部分[9]。與其他認證方式不同的是，Passport 單點登錄采用集中式認證、分布式授權方式，即用戶的身份認證由Passport 負責，而資源的授權由每一個應用系統上的內容授權程序來完成。Passport 同樣采用Cookies來存儲票據，所有認證信息由客戶端保存和轉發，不需要與應用系統之間進行交換，增加了認證過程的安全性。但Passport 僅支持傳統的用戶名和密碼認證方式，可擴展性較差。

（5）Liberty。自由聯盟計劃（liberty alliance project，簡稱Liberty）[10]是由SUN、HP、Sony、AOL等40 余家成員單位在2001 年聯合成立的主要為大中型網絡提供分布式認證服務的組織。為了適應大型網絡中的單點登錄功能，Liberty 允許根據需要建立多個用戶身份認證中心，而且加盟的站點與用戶身份認證中心之間可以建立一對多或多對多的聯盟關系，不同的用戶身份認證中心之間也可以建立聯盟關系。Liberty 利用SAML 實現在多信任域內的單點登錄，實現的自由度較高。

（6）Kerberos。Kerberos 是一種在開放網絡環境中用于用戶與待訪問資源間進行相互認證的協議[11]。例如，當用戶A 訪問資源B 時，不但資源B 要驗證用戶A 身份的合法性，而且用戶A 也要驗證資源B的真實性。為了實現這一功能，Kerberos 引入一個稱為KDC（key distribution center，密鑰分發中心）的權威第三方，所有的用戶名、密碼等用戶信息憑證及應用系統的標識信息全部集中存放在KDC 中。這樣，當用戶A 訪問資源B 時，利用KDC 就可以驗證雙方的身份，用戶A 與資源B 之間都不知道對方的身份信息。基于Kerberos 的單點登錄使用對稱加密機制，效率較高，但無法應對重放攻擊，且密鑰管理較為復雜，系統的可擴展性較差，僅適用于安全要求不高的小型網絡。目前，一些基于Kerberos 的單點登錄系統基本上是在傳統Kerberos 基礎上的改進方案。各種單點登錄解決方案和應用產品的比較如表1 所示。

表1 各種單點登錄解決方案和應用產品的比較

通過以上對比分析，由于CAS 能夠很好地支持非Web 應用的單點登錄功能，非常符合目前高校實驗室建設現狀和管理需要，而且系統的可擴展性較高，另外開源的CAS 為系統設計和開發提供了便捷性。為此，本方案選擇CAS 作為具體的開發平臺。

2 基于CAS 的實驗室統一身份認證方案設計

2.1 統一身份認證用戶數據庫的設計

在圖1 所示的統一身份認證方案中，有一個集中存放用戶名、密碼等用戶信息憑證的空間，即用戶信息數據庫。由于統一身份認證系統中主要存放的是用戶信息憑證，如果使用傳統的關系數據庫，不但管理不便，而且運行效率很低。本方案采用 LDAP（lightweight directory access protocol，輕量級目錄訪問協議）[12]來組織和管理用戶信息憑證。LDAP 采用樹型結構組織和管理用戶信息憑證，通過一張邏輯視圖對外提供用戶查詢服務，已經成為TCP/IP 網絡中一個事實上的目錄服務標準。

作為目前應用最為廣泛的目錄服務標準，在基于單點登錄的統一身份認證中，LDAP 具有以下特點：對讀取用戶信息憑證方法進行了優化，采用基于TCP/IP 的分布式存儲方式，可根據需要擴展所存儲的信息種類，提供高級檢索功能，可實現目錄服務信息在目錄服務器之間的同步操作等。

結合CAS 的特點，本方案采用Open LDAP 作為統一身份認證用戶信息憑證的目錄服務器。Open LDAP 是一個開源平臺，包括了LDAP 服務器和開發工具，主要應用于Linux，也可移植到Windows 系統。本方案整體采用基于CAS 和LDAP 的單點登錄統一身份認證方式，其中CAS 由CAS Server 和CAS Client兩部分組成，其中CAS Server 作為統一身份認證中心，為開發人員提供了可按需擴展的定制化認證界面，用戶身份信息憑證存放在LDAP 目錄數據庫中，在用戶認證時供CAS Server 查詢使用。CAS Client 集成在應用系統中，負責將用戶身份認證請求重定向到CAS Server，并通過設置3 個不同的URL 實現與CAS Server 之間的登錄、驗證及注銷操作。

2.2 基于CAS 單點登錄方案的設計

基于CAS 單點登錄的統一身份認證方案的設計思路是：當用戶第一次訪問信任域中的某一授權實驗系統時，因為還沒有進行登錄，所以會被重定向到CAS 統一身份認證服務器；CAS 統一身份認證服務器根據用戶登錄時輸入的用戶名、密碼等用戶信息憑證進行身份驗證，如果驗證通過，則生成一個訪問票據返回給用戶；當用戶繼續訪問信任域中的其他授權實驗系統時，將會攜帶該訪問票據作為身份驗證的依據，當實驗系統將該訪問票據提交CAS 統一身份認證服務器進行驗證后，用戶將無須再次進行登錄操作就可以直接訪問。

為了實現單點登錄功能，CAS 提供了全局票據TGT（ticket granting ticket）、服務票據ST（service ticket）和全局會話TGC（ticket granting cookies），其中TGT 是CAS Server 為Web 用戶簽發的登錄票據，擁有TGT 的用戶說明已經成功地在CAS Server 上進行了身份認證；ST 是CAS Server 為用戶簽發的用于訪問某一應用系統時的訪問票據；TGC 是TGT 的唯一標識（ID），被作為用戶瀏覽器與CAS Server 之間的訪問憑證存放在用戶端，TGC 在用戶與CAS Server之間傳輸時采用HTTPS 協議。基于CAS 單點登錄的統一身份認證方案的工作流程如圖2 所示，具體描述如下：①用戶以Web 方式訪問實驗系統1 中的授權訪問資源；②實驗系統1 發現該用戶尚未進行身份認證，于是將用戶請求頁面重定向到CAS Server；③用戶輸入用戶名、密碼等用戶信息憑證；④CAS Server 在LDAP 目錄服務器中進行用戶信息的比對，并獲得注冊時提交的完整用戶信息；⑤CAS Server 生成用于證明該用戶已進行了身份認證的TGC，并簽發針對該用戶訪問實驗系統1 時使用的ST；⑥CAS Server 將TGC和針對實驗系統1 的ST 以Cookies 的方式發給用戶；⑦用戶的Web 訪問頁面被重定向到實驗系統1，同時該訪問頁面中攜帶針對實驗系統1 的ST；⑧實驗系統1 向CAS Server 驗證ST 的有效性；⑨實驗系統1 通過ST 有效性驗證后，生成一個局部會話Cookies，并返回給用戶；⑩用戶將以該會話Cookies 作為訪問憑證，再次訪問實驗系統1 中的授權訪問資源。

經過以上的操作流程，用戶與CAS Server 之間以TGC 作為身份認證的憑證，應用系統與CAS Server之間以ST 作為有效性驗證憑證，用戶與應用系統之間通過Cookies 建立會話連接，實現了統一身份認證功能。當用戶再次訪問信任域中的其他應用系統（如實驗系統2）時，與訪問實驗系統1 時的區別在于第2步實驗系統2 重定向到CAS Server 時，請求報文中已經攜帶有標明用戶身份的TGC 票據，CAS Server 在接收到該認證請求時會自動簽發ST，而不必再進行后續煩瑣的認證過程，而且所有操作是透明的，不需要用戶參與，實現了單點登錄功能。

本方案中，由于用戶與實驗系統之間采用Cookies方式進行認證，當用戶通過點擊“退出”按鈕或關閉Web 瀏覽器退出系統時，用戶首先通知CAS Server注銷TGC，然后CAS Server 注銷簽發給各應用系統的ST，實現了各應用系統的自動退出。

圖2 基于CAS 的單點登錄統一身份認證流程

3 基于CAS 單點登錄的實驗室統一身份認證的實現

本文主要介紹CAS Server 與CAS Client 兩個關鍵部分的部署方法。CAS 軟件的下載及完整部署方法可參考https://github.com/apereo/cas。

3.1 CAS Server 的部署

CAS Server 的部署主要涉及運行環境配置和LDAP 目錄數據庫的配置兩個方面。其中，CAS Server存放并運行在Web 容器（本例為Tomcat）中，CAS官方推薦采用overlay（系統提供的一個配置模板）方式來配置服務器，可根據要求將修改或定制好的配置文件覆蓋掉原來的模板（cas-overlay-template）即可。同時，配置時需要啟用CAS Server 的單點登錄功能，并生成管理CAS Server 的安全證書（具體可使用Java自帶的keytool 證書管理工具）。另外，還需要在Tomcat的配置文件erver.xml 中添加對HTTPS 協議的支持。

在進行用戶身份信息驗證時，CAS Server 需要在LDAP 目錄數據庫（本方案采用OpenLDAP）中讀取相關的用戶信息，為此需要創建 CAS Server 與OpenLDAP 之間的連接，具體可通過修改WEB-INF/deployerConfigContext.xml 文件來實現。為了提高應用的安全性，可在配置中通過選擇加密算法對保存在OpenLDAP 中的用戶信息進行加密處理，在網絡中傳輸用戶信息時使用HTTPS 協議。

3.2 CAS Client 的部署

CAS Client 支持Java、.NET、PHP、Apache、Perl等多種客戶端，以庫的形式集成在可信任域中授權訪問資源所在的系統中，以保護資源不被非授權用戶訪問。CAS Client 的具體實現方式是將用戶請求重定向到統一身份認證中心，交由CAS Server 進行處理。

CAS Client 的主要功能是進行頁面的重定向，即將用戶的請求URL 跳轉到認證頁面或重定向到需要訪問的應用系統，具體可通過配置 CAS 的過濾器（Filter）功能來實現。CAS 提供了AuthenticationFilter、TicketValidationFilter、HttpServletRequestWrapperFilter和AssertionThreadLocalFilter 共4 個功能不同的過濾器，可按需要進行配置[13]。圖3 所示的是本方案實現的統一身份認證中心用戶登錄界面。

圖3 統一身份認證中心用戶登錄界面

4 結語

本文以數字實驗室系統資源應用和管理整合為背景，介紹了基于單點登錄的統一身份認證系統的設計和建設方法，為相關高校提供了一個可供借鑒的技術方案。該方案采用開源的CAS 作為單點登錄支撐系統，選擇開源的OpenLDAP 作為統一身份認證目錄服務器，系統部署和維護較為方便，可擴展性較強，安全性較高，符合高校實驗室的建設特點和管理要求。