身通常表示 J2EE 应用程序中的权限集合。

 

　　实际定义哪些用户属于哪些组是在用户注册中心中进行管理的。这可以是企业 LDAP 

 

服务器，也可以是仅由单个应用程序使用的数据库，但用户和组信息的存储库位于 J2EE 

 

环境之外。在 J2EE 应用程序内，您可以基于这些角色定义和命名安全角色及约束资源访
问。因此，角色是权限集合;为了使用它，必须在部署应用程序时将其绑定到某一组用户。
可以按名称将其映射到一个或多个用户，也可以映射到一个或多个用户组，还可以映射
到二者的任意组合。术语主体通常是指用户或用户组。

 

　　您将看到，虽然 J2EE 角色可能通过简单的一对一映射紧密地映射到注册中心组，
但 并 不 一 定 非 得 如 此 ;

“

在 最 简 单 的 情 况 下 ， 可 以 将 manager” 角 色 映 射 到 称 为

“manager”

 

的组，但 J2EE 角色的强大之处在于，它提供了出色的灵活性，能够在组织

发生更改时更改绑定，而无需进行编程更改。以下列情况为例，假定特定的应用程序功能

 

仅对法律部门的员工可用，而这些员工都属于 Department 102。可以在应用程序中创

“

建一个名为 legal”  

的 J2EE 

“

角色，并绑定到注册中心组 Dept102”。如果以后对该部门

 

进行了重组，其中一半的员工转到了 Department 507，则可以更改绑定，以映射到
“Dept102” “

和 Dept507”。然后，当属于这两个部门的任何员工经过了系统的身份验证

“

后，就会向其授予 legal”角色，系统会向其提供恰当的访问权限。
　　自定义基于角色的授权

 

　　即使使用编程 API

 

，仍然会有因 J2EE 角色模型不够灵活而难以满足业务需求的情况。

 

不过，在草率行事前，应该对以 J2EE 模型为基础(而不是将其替换)进行构建的可能性进
行分析。这样做的优势包括：
　　利用本机应用服务器身份验证对创建完全安全的系统至关重要。
　　良好的安全性可提供深度防御;使用多种方法并不一定是坏事。

 

　　可以首先使用 J2EE 执行基本的声明性安全功能，然后使用自定义方法来执行更为
详细的身份验证逻辑。
　　从头编写可以免费获得的功能并不划算!
　　另外要注意，有时候，可以通过应用服务器安全运行时的其他可插入功能来获得所
需的灵活性。例如，如果需要角色-组映射在运行时具有动态性(根据用户登录时提供的信
息)

 

，则可以使用 JAAS 

 

登录扩展来满足此需求。在 WebSphere Application Server 

V5.1.1 

 

或更高版本中，可以在 Trust Association Interceptor   

或 JAAS 登录模块中创

建动态组成员身份。不过，如果角色与上下文相关(基于具体的应用程序使用情况)，则可
能需要购买或构建授权框架。医疗应用程序就是上下文使用模式的一个例子：医生可以一
次性登录到系统，但根据所查看的病人或医疗实体(如医院或诊所)的上下文的不同，该
医生的角色可能会从检查医师更改为主治医师。此更改是在会话过程中动态更改的，而不
仅限于进行身份验证时可用的信息。

 

　　只要认为 J2EE 应用程序授权本身不足以解决您的问题，下一个问题就是要确定是
否构建或购买授权解决方案。IBM Tivoli® Access Manager 等企业安全产品提供了灵
活的、基于策略的功能授权。不过，将这些功能与应用服务器相集成可能有一定的挑战性。
您需要考虑的一些问题包括：

 

　　是否使用专用 API?
　　将提供何种功能?
　　授权请求外部化会带来何种性能损失?
　　Java™ Authorization Contract for Containers (JACC) 是一种基于标准的方法，