統一登錄框架設計及其與Ｒｅｓｉｎ容器的融合實現

摘要：設計一種結構將多個獨立的Web應用集成為一個整體，使用戶僅需一次登錄即可完成在所有應用下的認證，實現各應用間的自由轉換。結合Resin容器自身的認證授權機制，通過設計實現Resin下Authenticator類的一個子類SSOAuthenticator，使Resin容器與統一登錄框架達到無縫融合，保證用戶使用的透明性。

關鍵詞：統一登錄; Resin容器; Authenticator

中圖法分類號：TP393．09文獻標識碼：A

文章編號：1001－3695(2007)01－0272－03

統一登錄框架是目前備受關注的新型登錄模式，通過提供對多個獨立Web應用的整合策略，使用戶可以實現框架內的“一次登錄，處處暢通”。與傳統的登錄模式相比，它具有三個方面的優勢：

①減少了用戶依次對各個應用進行登錄的操作時間，從而降低了人工操作的失誤率；

②減少了用戶需要記憶的密碼信息對，從而提高了系統的安全性；

③對多個應用統一身份管理，方便了系統管理員對用戶身份的管理操作，提高了系統的反饋性能。

Resin是Caucho公司開發的一套支持J2EE標準的Web容器。由于它的簡潔易配和對XML技術的良好支持性，使其在中小應用開發中得到了廣泛的應用。用戶在開發時，利用Resin自身提供的認證授權機制，只需進行少量配置，就可以實現一套完整的認證授權系統。因此，利用Resin下已有的認證授權體系，將Resin納入到統一框架中，可以將Resin的易配置性和框架的通用性相結合，提高統一登錄框架的實用效能。

出于以上目的，本文給出一個統一登錄框架的總體設計，并針對Resin下已有應用，遵照Resin的認證授權體系，提供Resin與框架的無縫融合實現。

1統一登錄框架的總體設計與實現

1．1設計思想

統一登錄框架在設計時需要考慮的主要方面有：

①一致性，用戶在框架內的各個應用的身份認證應具有一致性，在應用間轉換訪問不需要進行重復登錄；

②通用性，框架應能提供對多種應用環境的支持，能夠實現無差別的統一訪問；

③易用性，在將已有應用納入框架時，應該保證盡量減少對應用的改造工作，減少用戶的使用配置，方便用戶使用。

基于以上三個方面的考慮，本框架決定采用基于請求代理的策略實現（圖1）。基本思想是建立一個統一的Portal服務器來代理所有的應用站點的Web請求，由這個Portal服務器來統一處理用戶的認證登錄。這里需要說明的是盡管這個Portal服務器統一代理所有的Web請求，但實際上真正進行處理的僅僅是用戶認證方面的相關請求，對于已認證用戶的Web請求，僅僅是通過URL轉發將請求傳給應用站點。基于這種策略當未認證用戶訪問某應用站點時，Web請求將先被傳入Portal服務器進行用戶認證，用戶完成認證后再由Portal服務器將請求轉回應用站點，并將用戶的身份信息包括在請求中一并轉回。

圖1基于請求代理的認證策略

基于這種策略實現認證需要建立服務器與應用站點間的信任關系，以便認證后的用戶身份能夠被應用承認。其實現機制簡潔，結構框架更靈活，對原有Web應用的改造較少，能夠充分滿足對于框架一致性、通用性和易用性的設計要求。

1．2交互協議的約定

為更好地保證通用性，實現Portal服務器與應用間的信息交互，我們為框架制定了基于HTTP的交互協議。協議主要是針對Portal端與應用端的各種交互操作，約定信息格式，以保證任何實現協議規定的應用均可以納入到統一登錄框架中。

下面針對框架下六種操作給出相應的具體規定（注：在協議中出現的代稱如果拼寫相同，則在沒有特殊說明的情況下具有相同意思）：

(1)應用站點需要對用戶身份進行認證時，將用戶請求重定向到Portal服務器。重定向請求應該遵從以下格式：

url=http://portalURL?reqURL=appSiteURLmaxinterval=session￣ActiveTimecode=randomNum

其中portalURL為Portal站點的URL地址，appSiteURL為本應用站點中用戶請求資源的URL地址（下同），sessionActiveTime為應用站點會話（Session）保持時間，randomNum為認證源碼，可以為隨機數或者時間戳等。應用站點通過客戶端瀏覽器的臨時Cookie或其他方式保存此處的認證源碼，以便在Portal服務器完成認證將請求返回時，可以進行認證碼的校驗，從而確定用戶身份的合法性。

(2)用戶在Portal端認證或注冊完成后，請求重定向返回應用站點。

這個時候應用站點需要能夠識別出Portal端返回的正確認證的用戶信息，并能夠通過檢驗認證碼來確保該認證信息的合法性。

返回請求的格式為

url=http://appSiteURL?logIdentify=***userID=****code=*****

其中logIdentify的值為用戶登錄Portal服務器時產生的唯一標志，userID的值為用戶登錄所用的用戶名，code為Portal端處理后返回的認證碼。為了防止有人惡意假冒，只有通過了認證碼校驗的身份信息才為有效信息。

(3)當用戶登錄并與應用站點之間建立了會話連接后，若由于某種原因（如長時間在該應用站點沒有動作）導致用戶在應用站點的會話過期（Session Timeout），則當用戶再次請求訪問該應用站點的受限資源，應用站點重新將用戶請求重定向到Portal端認證服務器。

此時重定向URL格式與操作(1)相同。

(4)Portal對用戶全局會話狀態的定期查詢操作。

本操作主要是判斷已登錄用戶在各個應用是否仍然處于有效會話期，以便及時更新Portal上的用戶登錄日志。Portal將通過重定向請求的方式在應用站點之間查詢用戶的會話狀態。

查詢請求的格式為

url=http://appSiteURL?action=query

其中action=query標志此請求是全局狀態查詢動作。

當應用站點接收到這種請求時，要求對全局狀態查詢的動作作出反應。生成反饋格式為

url=http://portalURL?action=queryreqURL=appSiteURL maxinterval=sessionActiveTime

其中sessionActiveTime為用戶的會話保持時間，由用戶在應用站點的會話狀態決定。當用戶是經過認證的有效用戶且在該應用站點仍然處于有效會話期時，sessionActiveTime的值為該應用站點的默認會話保持時間；當用戶在應用站點會話已過期時， sessionActiveTime值為0。在此處，反饋URL中action=query標志本次請求是對全局狀態查詢的反饋。

(5)用戶注銷操作。

用戶觸發注銷操作后，瀏覽器被重定向到應用站點。重定向請求的格式為

url=http://appSiteURL?action=logout

其中 action=logout表明是請求為注銷操作。

當應用站點接收到這種注銷指示后，中止對應用戶在該應用站點的會話，同時生成請求反饋，格式為

url=http://portalURL?action=logout

其中action=logout表示本次重定向是對注銷操作的反饋。

(6)Portal對應用站點連接狀態的定期查詢操作。

為了檢查框架下各應用站點的可連接性（可連接性指應用服務器處于活動狀態，且在網絡上是可達的），Portal服務器會定期地自動向各個應用站點發HTTP請求。應用站點收到Portal的請求后需要給予回應，以表明自己處于可連接狀態。

Portal認證服務器向應用站點發HTTP請求，格式為

url=http://appSiteURL?action=portalQuery

其中action=portalQuery表示本次HTTP請求是Portal站點發來的查詢請求。

應用站點對該HTTP請求作出狀態答復，格式為

url=http:// portalURL?state=alive

其中state=alive標志應用處于可連接狀態。

1．3結構模塊

框架的主要功能模塊分為應用入口模塊、認證登錄模塊和注銷模塊三部分。其中應用入口模塊置于系統框架下的各個Web應用站點，采用Filter技術處理Web請求，提供與Portal端的交互功能；認證登錄模塊和注銷模塊統稱為服務器模塊，置于登錄服務器Portal上，分別負責為應用站點提供認證登錄服務和用戶注銷服務（圖2）。應用入口模塊根據應用站點的服務環境的不同，提供不同的接入實現，如后文提到了SSOAuthenticator就是一個Resin環境下的接入模塊中的主要組成部分。與應用入口模塊這種實現的多樣性相對的是服務器模塊也就是認證登錄模塊和注銷模塊的唯一性。這種服務器模塊的統一性和應用模塊的多樣性保證了框架的通用性，即實現了跨應用環境平臺的統一登錄。

圖2基于Web請求代理的統一登錄框架

2Resin容器的融合設計與實現

2．1Resin容器的認證授權機制分析

Resin容器自身擁有一套完整的認證授權機制。該機制利用了Filter技術，將所有訪問受限資源的請求截獲，對于其中未認證的用戶將請求轉向指定的登錄頁面，由指定的Authenticator來處理用戶認證；而對于認證通過的用戶，容器將根據其用戶身份獲取對應的角色信息，進行訪問控制。

用戶在進行應用開發時，僅僅需要對web.xml文件進行簡單的配置操作，即可實現完整的認證授權系統。配置文件樣本如下：

＜ｌｏｇｉｎｃｏｎｆｉｇ＞

＜ａｕｔｈｍｅｔｈｏｄ＞ｆｏｒｍ＜／ａｕｔｈｍｅｔｈｏｄ＞

＜ｆｏｒｍｌｏｇｉｎｃｏｎｆｉｇ ｆｏｒｍｌｏｇｉｎｐａｇｅ＝′／ｌｏｇｉｎ．ｊｓｐ′

ｆｏｒｍｅｒｒｏｒｐａｇｅ＝′／ｅｒｒｏｒ．ｊｓｐ′／＞

＜ａｕｔｈｅｎｔｉｃａｔｏｒ ｉｄ＝′ＪＤＢＣＡｕｔｈｅｎｔｉｃａｔｏｒ′＞

＜ｒｏｌｅｑｕｅｒｙ＞

ＳＥＬＥＣＴ ＲＯＬＥ ＦＲＯＭ ＵＳＥＲ ＷＨＥＲＥ ＵＳＥＲＩＤ＝？

＜／ｒｏｌｅｑｕｅｒｙ＞

＜／ａｕｔｈｅｎｔｉｃａｔｏｒ＞

＜／ｌｏｇｉｎｃｏｎｆｉｇ＞

＜ｓｅｃｕｒｉｔｙｃｏｎｓｔｒａｉｎｔ＞

＜ｗｅｂｒｅｓｏｕｒｃｅｃｏｌｌｅｃｔｉｏｎ＞

＜ｕｒｌｐａｔｔｅｒｎ＞／ａｄｍｉｎ／＊＜／ｕｒｌｐａｔｔｅｒｎ＞

＜／ｗｅｂｒｅｓｏｕｒｃｅｃｏｌｌｅｃｔｉｏｎ＞

＜ａｕｔｈｃｏｎｓｔｒａｉｎｔ ｒｏｌｅｎａｍｅ＝′ａｄｍｉｎ′／＞

＜／ｓｅｃｕｒｉｔｙｃｏｎｓｔｒａｉｎｔ＞

…

其中formloginpage指定登錄頁面，formerrorpage指定出錯處理頁面，Authenticator指定處理認證信息的類，Securityconstraint指定受限資源及其授權角色。

在Resin容器自身的這套認證授權機制中也加入了對于統一登錄的考慮，但是僅僅局限在對同一個Resin容器下應用的統一登錄，因此，需要重新改造才能將其完全接入已有的框架中。

通過分析Resin源代碼，可以發現Resin的認證授權機制中的授權部分實際上是從屬于認證部分的。而認證部分的主要工作由Authenticator來完成，所以將Resin融入框架的關鍵就在于實現Resin開發包中的抽象類Authenticator的一個合適的子類。

2．2對Resin環境下的入口模塊設計

由于Resin認證授權機制的基本思想與統一登錄框架下應用入口模塊的設計思想基本吻合，均采用Filter技術來截獲請求，所以在Resin環境下應用入口模塊的設計上可以省去Filter的實現，只需考慮與服務器模塊的交互通信。通過對Resin機制的分析，首先考慮設計一個 SSOAuthenticator繼承抽象類Authenticator。而不同于一般的Authenticator子類的是，它本身并不對用戶認證信息進行處理，而主要負責與Portal服務器的交互工作，由Portal服務器進行統一的認證；同時它還需要遵從Resin的機制，能夠根據該用戶的身份信息獲取對應的角色信息完成訪問控制。

其次與服務器的交互方面，由專門的信息模塊負責交互信息的抽取和轉發，模塊的設計遵從框架約定的通信協議；內部模塊間的交互控制，由SSOAuthenticator負責，同時負責實現Resin的認證授權功能。具體實現按照J2EE規范，復寫getUserPrincipal￣Impl()方法，根據從服務器傳回的認證用戶的身份信息構造一個Principal對象，并復寫isUserInRole()方法以便獲取對應的用戶角色。

2．3使用配置

完成應用模塊設計后，將Resin下的應用接入框架時，用戶只需按照Resin規范對web.xml文件中的原有應用配置進行兩處修改（黑體部分），即將formloginpage修改為指定的RedirectServlet，將Authenticator指定為SSOAuthenticator即可。以2.1中的應用樣本為例，修改后的配置文件如下：

＜ｌｏｇｉｎｃｏｎｆｉｇ＞

＜ａｕｔｈｍｅｔｈｏｄ＞ｆｏｒｍ＜／ａｕｔｈｍｅｔｈｏｄ＞

＜ｆｏｒｍｌｏｇｉｎｃｏｎｆｉｇ ｆｏｒｍｌｏｇｉｎｐａｇｅ＝′／ｓｅｒｖｌｅｔ／ｃｎ．ｃｓｄｂ．ｓｓｏ．ｒｅｓｉｎＡｕｔｈ．ＲｅｄｉｒｅｃｔＳｅｒｖｌｅｔ′

ｆｏｒｍｅｒｒｏｒｐａｇｅ＝′／ｅｒｒｏｒ．ｊｓｐ′／＞

＜ａｕｔｈｅｎｔｉｃａｔｏｒ ｉｄ＝′ｃｎ．ｃｓｄｂ．ｓｓｏ．ｒｅｓｉｎＡｕｔｈ．ＳＳＯＡｕｔｈｅｎｔｉｃａｔｏｒ′＞

…

＜／ａｕｔｈｅｎｔｉｃａｔｏｒ＞

＜／ｌｏｇｉｎｃｏｎｆｉｇ＞

…

3結束語

統一登錄框架的主要意義在于實現多應用環境的集成。良好的一致性、通用性和易用性是設計統一登錄框架時必須考慮的基本因素。本文以Resin環境為例，詮釋了框架在這三個方面的實現。實際上，以上三個方面僅滿足了統一登錄框架的基本要求，隨著統一登錄技術的普及，對于安全性方面的考慮將成為衡量框架設計優劣的重要標準。如何在滿足一致性、通用性和易用性的基礎上，更好地保證系統的安全，將成為統一登錄框架今后發展的方向。

參考文獻：

［1］The Open Group.X/Open Single SignOn Service (XSSO) Pluggable Authentication Modules[EB/OL].

http://www.opengroup.org/bookstore/catalog/u039.htm，199903.

［2］Brian Gilmore， et al. Core Middleware and Shared Services Studies Single SignOn Report[EB/OL]. http://www.jisc.ac.uk/index.cfm?name=prog_middss_studies，20-040922.

［3］Garman， Jason. Single Signon for Your Web Applications with Apache and Kerberos[EB/OL].

http://www.onlamp.com/pub/a/onlamp/2003/09/11/kerberos.html，20030911.

［4］Chris Dunne. Technical Director， Big Picture Software. Build and Implement a Single SignOn Solution[EB/OL].http://www106.ibm.com/developerworks/ web/library/wasinglesign/，20030930.

［5］Shannon B. Java2 Platform Enterprise Edition Specification v1.4[Z]. Sun Microsystems Inc.

［6］Johannes Fiala. Sharing Session Data between Contexts HOWTO[EB/OL].http://archives.realtime.com/pipermail/tomcatusers/2003May/112539.html，200305.

［7］John Bell， Tony Loton. Java Servlets 2.3編程指南(Professional Java Servlets 2.3)[M]. 北京：電子工業出版社， 2002.

［8］Authentication with Resin Authorization with Resin[EB/OL]. http://www.caucho.com/resin3.0/security/index.xtp.

作者簡介：

續巖(1981)，男，碩士研究生，主要研究方向為大規模科學數據共享技術；

閻保平（1950），女，研究員，博導，博士，主要研究方向為大規模科學數據共享技術、數據網格技術與應用等；

季永志（1980），男，碩士研究生，主要研究方向為大規模科學數據共享技術；

吳開超（1971），男，高級工程師，主要研究方向為大規模科學數據共享技術。

注:本文中所涉及到的圖表、注解、公式等內容請以PDF格式閱讀原文