[評論]
摘要：
一個實際的應用系統除了需要關注於功能需求之外，還需要考慮很多非功能性需求，安全性就是其中一個非常重要的方面。訪問控制是幾乎所有的應用系統都不可缺少的一部分。
雖然J2EE架構提供了一套安全機制來幫助應用程序實現訪問控制，然而過於粗糙的控制粒度使得其使用價值幾乎爲零，爲此各個應用系統不得不各自開發自己的訪問控制模塊。
然而各個應用系統單獨使用各自開發的訪問控制模塊有着諸多的不利影響。
本文將描述一個基於開放的Weblogic Security Framework的J2EE通用訪問控制模塊，這樣既可以極大的提高應用系統構建速度也可以減少企業浪費在用戶管理上的精力。
目錄：
一、背景
二、設計目標
三、系統設計
1． 架構概覽
2． 實體關係
3． 應用系統接口層的設計
4． 管理工具的設計
5． API層的設計
6． 數據訪問層的設計
7． 數據存儲層的設計
四、不足與問題
五、總結
六、參考文檔
關於作者
一、背景(目錄)
一個實際的應用系統除了需要關注於功能需求之外，還需要考慮很多非功能性需求，安全性就是其中一個非常重要的方面。訪問控制是幾乎所有的應用系統都不可缺少的一部分。
雖然J2EE架構提供了一套安全機制來幫助應用程序實現訪問控制，然而過於粗糙的控制粒度使得其使用價值幾乎爲零，爲此各個應用系統不得不各自開發自己的訪問控制模塊。
然而各個應用系統單獨使用各自開發的訪問控制模塊有着諸多的不利影響，
1． 不利於應用系統的構建速度。每開發一個新的系統都需要重新開發一個訪問控制模塊。
2． 不利於企業集中管理各個應用系統的賬號及權限。每個應用系統使用各自的訪問控制模塊使得企業需要維護數目衆多的用戶信息，一方面造成信息冗餘，另一方面也難以維護用戶信息，爲安全帶來隱患。
因此，有必要創建一個通用的訪問控制模塊，這樣既可以極大的提高應用系統構建速度也可以減少企業浪費在用戶管理上的精力。
二、設計目標(目錄)
1． 支持用戶認證與授權，用戶信息管理。
2． 通用性。該模塊應該能夠容易地被不同的J2EE應用系統所採用，使得多個系統可以採用同一套用戶認證與授權機制完成訪問控制。
3． 集中管理與分級管理相結合。所有用戶信息和訪問控制相關的設定都應該集中控制，同時允許不同級別的管理員根據授權管理各自範圍內的資源。
4． 可擴展性。該模塊應該能夠容易的擴展新的訪問控制屬性。
5． 低侵入性。採用聲明式訪問控制，無需在業務代碼中添加訪問控制語句。然而爲了某些局部訪問控制的需要，同時提供編程式訪問控制。
6． 易用性。該模塊應該容易被開發人員和管理人員理解與使用。
三、系統設計(目錄)
1． 架構概覽
在這個通用訪問控制模塊裏，API層（藍色）是核心，該層次負責查詢數據存儲，響應應用系統接口層(黑色)關於訪問控制信息的查詢和操作。應用程序也可能通過編程性訪問控制直接與API層交互。
應用系統接口層(黑色)是提供給應用系統使用的。應用系統利用這一層次的功能完成具體資源的訪問控制。在這一層次裏，還提供了一些工具用於管理和配置資源的訪問控制信息。
數據訪問層（粉色）負責訪問具體的數據存儲，比如LDAP Server，數據庫，XML文件等等，在這一層次上可以插接不同的數據訪問器以適應不同的數據存儲形式。
數據存儲層（綠色）則是實際保存訪問控制信息的物理載體。
2． 實體關係(目錄)
我們把一個應用系統權限控制中所涉及的實體分爲三個部分：資源、應用、和用戶。
資源分爲功能性資源和業務性資源，功能性資源是指某個URL或者EJB的某個業務方法這類應用程序的功能部件。業務性資源則是指應用程序所操作的數據或其他對象。一個應用程序所有resource的集合構成了一個domain。在domain裏，一組resource的ACL（訪問控制列表）的集合構成了一個realm。一個應用程序可以訂閱一個realm的資源來實現對資源訪問的控制。
應用部分的主體是Application，Vendor做爲Application的提供商可以用來組織Application。Application可以劃分爲若干module，每個module對應若干action(操作)，定義在resource上的ACL（訪問控制列表）則定義了資源與Action的需求關係。定義在module下的role則是該module下action的組織方式。
用戶部分從Organization到department到user都是按照實際的行政劃分來組織用戶。Group則是一種補充的邏輯劃分。User與Role的聯繫則是RBAC（Role Based Access Control基於角色的權限控制）思想的具體實現。RBAC是解決複雜多變的企業權限管理的有效手段，它可以減小權限管理的複雜性，並且能夠靈活的定製和更改安全策略，具有良好的伸縮性。Role與group的聯繫並不是一種穩定的聯繫，需要通過User來實現，提供這種role與group間的聯繫是爲了方便批量的role的賦權與撤銷。organization通過訂閱application來實現用戶與操作的聯繫。
3． 應用系統接口層的設計(目錄)
傳統web應用程序的訪問控制可以通過使用servlet filter攔截請求來完成。對於Web應用程序來說，這種方式工作得非常好，但是對於非web資源，比如EJB，這種方式則起不到作用。
對於EJB，也可以使用某種proxy方式來代理訪問，以實現訪問控制，但是這種方式對應用程序具有侵入性，應用程序必須顯式的使用proxy纔行。
以上兩種方式的侷限性都在於僅僅對某一種資源起到訪問控制的作用。不能對整個J2EE系統內的資源以一種統一的方式進行訪問控制。
Weblogic Security Framework是一個開放的，靈活的安全框架，它除了適用於Web資源和EJB，還可以作用於JDBC connection pools，JMS destinations，JNDI和JCA Adapters等所有的J2EE資源。最爲關鍵的是它不但嚮應用系統提供了一個統一的安全界面，同時還提供了一種擴展機制，使你可以定製自己的訪問控制規則。
Weblogic Security Framework的架構如下圖所示
（來源：BEA White Paper - BEA WebLogic Security Framework:Working with Your Security Eco-System）
當訪問受保護的資源時，Weblogic Security Framework就會被激活，因此通過標準的J2EE安全機制，在部署描述符裏定義受保護的資源，就可以啓用我們的訪問控制系統。
比如在web.xml中如下的語句定義了protect.jsp爲受保護的資源，則在訪問此資源時Weblogic Security Framework將被觸發。
<security-constraint>
<web-resource-collection>
<web-resource-name>Success</web-resource-name>
<url-pattern>/protect.jsp</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>WeblogicUser</role-name>
</auth-constraint>
</security-constraint>
類似的，定義在ejb-jar.xml中的如下語句則定義了EJB的denyMethod方法爲受保護的方法，在client試圖訪問此方法時，也將觸發Weblogic Security Framework進行檢驗。
<method-permission>
<role-name>admin</role-name>
<method>
<ejb-name>Hello</ejb-name>
<method-name>denyMethod</method-name>
</method>
</method-permission>
當然由於使用自己定製的security provider，這些資源限制裏所涉及的role-name只是一個虛設的值，它將被忽略，而使用定義在我們的數據存儲中的用戶與role的對應關係。而web.xml中設定的login-error-page也將根據設置被替換，驗證失敗時用戶將看到更加豐富的定製信息。
下圖所示的是一個用戶登錄時所觸發的授權機制。
（來源：e-docs.bea.com Developing Security Providers for WebLogic Server）
下圖所示的是一個受保護的資源是如何與Weblogic Security Framework交互，以及Security Provider是如何發生作用的。
（來源：e-docs.bea.com Developing Security Providers for WebLogic Server）
通過替換Weblogic默認的Security Provider爲自定義的Security Provider，就可以實現我們自己的訪問控制。在這個系統裏，僅僅實現Authentication Provider和Authorization Provider就基本上能夠滿足需求了。
4． 管理工具的設計(目錄)
除了可以開發一個單獨的應用程序來管理所有的訪問控制資源之外，Weblogic還提供了一種叫做Administration Console Extension機制，可以讓我們把應用程序嵌入到Weblogic 的console中去，雖然這麼做的確是很cool，但是卻不利於授權的分層管理，因此單獨的管理工具還是必須的。
5． API層的設計(目錄)
在API層中，除了需要實現實體外，還需要設計提供給應用系統接口層的API，包括兩部分，一部分用於實現管理的API，也就是實體類的增、刪、改和查詢；另一部分用於實現用戶認證與授權的API，這一部分至少需要如下的API，
AuthenticateManager.authenticateUser(String userNmae, String password):UserInfo
用於檢驗用戶的登錄
AuthorizationManager.isProtectedResource(String resourceId):Boolean
用於測試資源是否受需要訪問授權
AuthorizationManager.isAccessAllowed(String resourceId, String userName):boolean
用於測試資源是否能夠被用戶訪問
6． 數據訪問層的設計(目錄)
數據訪問層必須可以允許插接不同的數據訪問器以適應不同的數據存儲形式，可以運用bridge模式+抽象工廠模式來實現這一點。
數據管理類比如UserInfoManager首先根據外部的設定值獲得一個具體的AccessorFactory，比如LDAPAccessoryFactory，然後使用這個具體的LDAPAccessoryFactory創建相應的Accessor來訪問物理存儲。
7． 數據存儲層的設計(目錄)
儘管可以使用多種存儲方式來保存訪問控制信息，但是LDAP無疑是最適合的存儲方式。我們的設計將提供一個基於LDAP的方案。
Weblogic Server裏內嵌了一個LDAP server，但是其功能實在是過於簡陋，不支持LDAP schema的擴展，因此並不能滿足我們的需求。因此在這裏我們將使用一個功能完整的LDAP server - SunOne Directory Server來表達設計，當然你可以把它移植到其他LDAP Server上去，比如免費的OpenLDAP server。
創建如下的attribute
djrole DirectoryString MultiValue
djaction DirectoryString MultiValue
djsubscribedapp DirectoryString MultiValue
djsubscribedrealm DirectoryString
創建如下的object class
djapplication parent top required attribute cn allowed attribute djsubscribedrealm
djappmodule parent top allowed attribute djrole, djaction
djdepartment parent organizationalunit
djdomain parent organizationalunit
djgroup parent organizationalunit attribute djrole
djorganization parent organizationalunit allowed attribute djsubscribedapp
djrealm parent top required attribute cn
djresource parent top required attribute cn allowed attribute djaction
djuser parent inetorgperson allowed attribute djrole
djvendor parent organizationalunit
這個schema只能滿足最基本的需求，根據需要可以進一步的擴充各個object class的屬性。
下圖是一個創建在SunOne Directory Server 5.2中的Directory Information Tree。
圖中標識出了每個entry所對應的object class。
四、不足與問題(目錄)
使用Weblogic Security Framework來攔截對受保護資源的調用，client端收到的響應也只能由Weblogic Security Framework發出，在處理EJB調用時，如果授權失敗，client端只能收到一個java.rmi.AccessException，我們無法給出更明確的信息來提示客戶端，這將妨礙這個權限控制系統的功能擴展。
用戶認證部分僅支持用戶名和密碼的方式，可能需要進一步擴展以支持更多的認證方式。
此外，這個系統還沒有包括審計部分，而審計也是安全管理的一個重要部分。其實Weblogic Security Framework也提供了對審計的擴展，需要時便可以添加。
五、總結(目錄)
Weblogic Security Framework以前所未有的開放性與靈活性爲實現這樣一個通用的J2EE權限管理系統提供了強大的支持。本文所涉及的只是冰山的一角，更多強大的功能還有待大家挖掘。
由於時間的關係，未能完成一個可運行的系統，只是做了一些驗證的原型，因此暫時無法將一套可運行的源代碼與大家分享。也許在不久的將來，大家會看到一個基於本文的開源系統。
六、參考文檔(目錄)
[1]Developing Security Providers for WebLogic Server http://e-docs.bea.com/wls/docs81/dvspisec/index.html
[2]BEA WebLogic Security Framework http://www.bea.com/content/news_events/ white_papers/BEA_WL_Server_TechSecurity_wp.pdf