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