http://dev2dev.bea.com.cn/techdoc/wlportal/2004110504.html
J2EE應用程序變得越來越復雜和普及，它們的管理也是如此。從大多數案例來看，我們需要一種授權機制將管理的權力從單個管理員手中延伸至多名管理員。通過這個過程，一個管理員可以分派特定的任務給下屬的其他管理員，他們將為原先那個唯一的管理員分擔管理壓力。
要理解管理工具構建過程中安全框架設計所涉及到的一些基本安全問題,我們就需要了解一些基本的安全概念。
身份認證與授權
身份認證是一個通過驗證用戶的身份來決定他是否被允許訪問某個給定系統的過程。認證過程一般是一個登錄過程，用戶需要提供一個用戶名和密碼。一旦用戶通過認證，一系列的“身份”(比如用戶名和用戶的會員資格)就與這個用戶建立關聯。這些身份通常也被稱為“職務”(Principals)。
授權，從另一方面來講，是一種根據通過身份驗證的用戶所對應的角色給予受控訪問被保護資源權力的過程。簡單的說，身份認證決定“誰”能訪問這個系統，授權則決定“什么”資源能被訪問。
根據用戶的職務而被授予相應的角色。系統通過授權機制阻止未被授權的用戶訪問受限資源則被稱為訪問控制。
基于角色的訪問控制(RBAC)
角色首先是構成訪問控制基礎的語義結構。使用基于角色的訪問控制，管理員們可以創建角色，給用戶指派一個角色，以及根據角色來定義被保護資源的訪問控制。通常情況下，管理角色就是根據用戶執行某些特定管理任務能力的來定義的。
聲明式授權與編程式授權
J2EE平臺定義了一個稱為部署描述符的文檔，用于描述如何建立安全契約。每個容器在它們各自的部署描述符中定義自己的 “范圍（scoped）”角色。
- 應用程序范圍（Application-scoped）的角色被定義在application.xml和weblogic-application.xml里。
- Web應用程序范圍（Web-application-scoped）的角色被定義在web.xml和weblogic.xml里，適用于Web項目的所有資源。
- EJB范圍（EJB-scoped）的角色被定義在ejb－jar.Xml和weblogic－ejb－jar.Xml，僅僅適用于EJB模塊的內部資源。
當聲明式授權不足以達到應用程序的安全需求時，安全感知的應用程序通常會選用編程式授權來表示它們的安全模型。比如在應用程序可能需要以天為單位來保護其資源的時候，或者更一般地說，需要根據業務需求情況來保護資源的時候。
Java 身份認證與授權
Java 身份認證與授權服務（Java authentication and authorization service，JAAS）是一組打包在Java 2 SDK 1.4中的API。這些API啟用了服務認證和服務授權服務。更多有關JAAS的信息，請參閱網址：http://java.sun.com/products/jaas/。
下面列出了一些重要的術語：
Subject：subject是一個實體(entity),它通過系統向對象(objects)發出請求來讓對象(objects)為它在系統中執行相應的功能，一般情況下，一個用戶對應于一個subject。
Principal：principal用來確定subject。subject由一個或多個相關的principal組成。比如，一個subject可以由兩個principal組成：WLS用戶（“bob”）和WLS用戶組（“developers”）。
Credential：credential是一個安全相關的屬性，它包含了可用于驗證新服務subject的信息。
構建管理工具的安全框架
管理工具有著非常特殊的安全需求。在用戶通過驗證并允許他們訪問管理工具后，需要“有選擇地”賦予不同管理員相應的管理能力，比如內容管理管理員只能訪問內容管理界面。這種功能可以通過授權機制（它決定了誰能訪問什么資源）來實現。通常情況下，管理能力與各自的管理任務相關聯，例如，管理員有管理用戶及其組會員資格的權限。這一管理任務可以進一步與諸如刪除用戶/組、創建用戶/組、修改組成員資格等能力相關聯。這種“基于能力”的授權稱為權利（entitlements）。
委托管理是一種重要的技術，它使得管理員可以 “pass-on”（傳遞） 權限給其他管理員。委托管理可以通過擴展權利框架來實現（例如，讓它內置于BEA WebLogic Platform 8.1)
總而言之，權利機制在受保護資源上增加了基于能力的控制，而委托管理則增加了管理任務上的控制。
角色和安全策略
安全框架應該支持用于定義安全約束(用于定義訪問“資源”的權限策略)的API。由于把這些策略與角色（比如RBAC）關聯在一起非常有利，單獨的策略可能需要定義這些角色。這些角色策略可能基于時間、日期、請求和會話屬性，以及用戶屬性，從而使這些策略具有動態特性。
因此，角色策略將定義角色和與那個角色相關聯的有授權約束的安全策略。定義和操作角色及安全策略的API對這種安全框架來說尤為必要。
資源范圍的角色
角色可以作用于同一應用程序的不同的資源范圍內。一個應用于部署在安全域(比如, 整個WebLogic Server domain)內所有資源的安全角色被稱為全局角色。一個應用于部署在安全域(例如某種特定門戶的資源)內某一資源的某一特定實例的安全角色被稱為范圍角色。管理員角色也需要根據哪些資源需要被管理來限定范圍。例如在BEA WebLogic Portal 8.1中，管理員角色的作用范圍包括整個企業應用程序。這是因為需要有一個能夠管理全部的Web 應用程序(每個Web 應用程序包含一個或多個門戶)的管理員角色。因此根據應用程序的需求，仔細考慮設定管理員角色的作用范圍是很有必要的。
角色層次
角色層次關系是建立在所有角色（roles）之間的一種部分順序關聯。在構建用于企業應用的管理工具時，我們需要緊緊地把握委托的發生方式以及控制方式，比如控制誰能對誰進行委托，角色層次圖可以滿足這項需求。在管理工具中，管理員（對應著某一角色）可能想要創建子角色，比如是另一些擁有有限管理權限的管理員。例如，一個擔任“Monitor”角色的管理員可以創建一個叫做“Sub-Monitor”的子角色，然后委托給他一部分管理員權限。圖1描述了這樣一種角色層次關系。
注意：在WebLogic Portal 8.1中， PortalSystemDelegator 是最頂層的角色， 一開始所有在“管理員”組群里的用戶都被映射到PortalSystemDelegator 角色上。
注意：在WebLogic Portal 8.1中，PortalSystemDelegator是委托開始的角色。“Administrators”組中的所有用戶都映射為PortalSystemDelegator角色。
圖1
BEA WebLogic Portal（WLP）管理工具
BEA WebLogic Portal 管理工具中涉及的概念已經在前面章節中介紹過了。
架構
BEA WebLogic Portal管理工具使得門戶應用程序的管理變得非常方便。委托管理功能是管理工具的必備部分。委托管理使用了門戶權利。WLP權利依次建立在WebLogic Server安全架構上，該安全架構是可插入的和基于服務提供接口（SPI）的（參見圖2）。
圖2
委托管理中有三個重要的安全模塊：角色映射、授權和審計。WLP權利框架中提供的RoleMapping API用于創建委托管理角色。這些角色具有層次結構。一個父角色（委托人）在允許的情況下可以創建子角色（被委托人）。它們由父角色管理（參見圖3）。在圖中可以看到“AlphaAdminRole”能管理一些“子”角色，如 BetaAdminRole、DeltaAdminRole和GammaAdminRole等，因為“父”角色已經授予了權限（參見圖3中的箭頭）。
圖3
委托管理角色
委托管理角色不同于其他標準訪問者角色。委托管理角色是作用在企業應用程序范圍內的，而一般的訪問者角色是作用于Web應用程序域內的。要想創建一個委托管理角色的話，一種方法是通過繼承叫做com.bea.p13n.entitlements.policy.RolePolicyItem 的公共類。
public class DelegatedAdminRolePolicyItem extends RolePolicyItem {
public DelegatedAdminRolePolicyItem(String aRoleName,
List users,
List groups,
String aRoleSegment,
P13nContextHandler aContextHandler) {
super(ApplicationHelper.getApplicationName(),
//All DA roles are enterprise-app scoped, hence the web-app = null
null,
aRoleName,
EntitlementConstants.ENT_APP_ROLE_INHERITANCE,
users, groups, aRoleSegment, aContextHandler);
} |
委托管理安全策略
安全策略定義了作用于管理任務的約束條件。它們定義了哪些角色有權力執行給定的管理任務。委托管理安全策略是com.bea.p13n.entitlements.policy.SecurityPolicyItem的一個特例。
public class DelegatedAdminSecurityPolicyItem extends SecurityPolicyItem {
public DelegatedAdminSecurityPolicyItem(String aWebAppName,
String aResourceId,
String aCapability,
List roles,
P13nContextHandler aContextHandler) {
super(ApplicationHelper.getApplicationName(),
aWebAppName,
aResourceId,
// delegated administration security policies are only going to be based on roles
null, null,
roles, aCapability, aContextHandler); super.setPolicyUser(EntitlementConstants.P13N_ADMIN_POLICY);
} |
安全策略評估
安全策略評估方案不同于Weblogic Portal 8.1的權利方案，它在委托管理資源上默認是沒有權限的，但該安全策略評估方案與管理需求密切相關。安全策略評估方案遵循稱為“授權重寫”（grant override）的算法。在這里安全策略是從資源層次圖的葉子節點開始評估的，然后沿著資源層次圖往上直到獲得一個“授權決定”（grant decision ）。如果一直到資源層次圖上的根節點仍沒有找到相應的授權決定，則返回一個否定決定。圖4（Portal管理工具的截圖）展示了這一安全策略評估方案的工作機制。在這里“Monitor”角色被授予對“fooGroup”資源的“Read User/Group”權限（請參閱管理能力）。
圖4
參見圖5，“Monitor”角色中的用戶將自動獲得任何子資源（比如sub-fooGroup）的“Read User/Group”權限。
圖5
結束語
設計和實現用于企業應用的管理工具可能非常復雜。本文中介紹的概念將有助于構建支持這些管理需求的安全框架。BEA WebLogic Portal 8.1 管理工具就建立在這一框架的基礎上。
原文出處：http://dev2dev.bea.com/products/wlportal81/articles/wlp81_devgan.jsp