基于角色的授权

使用授权信息以确定调用者是否拥有请求服务必需的特权。

下图说明了在授权期间使用的进程。

由 Web 协调程序处理 Web 客户机对 Web 资源的访问。来自 Java 客户机的 Enterprise JavaBeans (EJB) 资源访问 (无论是企业 Bean 还是 aservlet) 由 EJB 协作者处理。 EJB 协调程序和 Web 协调程序从对象请求代理 (ORB) 的当前对象中抽取客户机凭证。在认证过程中，将客户机凭证设置为在 ORB 当前对象中接收到的凭证。将资源和接收到的凭证提供给 WSAccessManager 访问管理
器以检查是否允许客户机访问请求的资源。

由 Web 协调程序处理 Web 客户机对 Web 资源的访问。来自 Java™ 客户机 (无论是企业 Bean 还是 servlet) 的 Enterprise JavaBeans (EJB) 资源访问由 EJB 协调程序处理。 EJB 协调程序和 Web 协调程序从对象请求代理 (ORB) 的当前对象中抽取客户机凭证。在认证过程中，将客户机凭证设置为在 ORB 当前对象中接收到的凭证。将资源和接收到的凭证提供给 WSAccessManager 访问管理器以检查是否允许客户机访问请求的资源。

访问管理器模块包含两个主要模块：

资源许可权模块帮助确定给定资源的必需角色。此模块使用应用程序启动期间由安全性运行时构建的资源至角色的映射表。要构建资源至角色的映射表，安全性运行时将读取企业 Bean 或 Web 模块（ejb-jar.xml 文件或 web.xml 文件）的部署描述符
授权表模块查阅角色至用户或组的映射表，以确定是否为客户机授予了一个必需的角色。角色至用户或组的映射表（也称为授权表）是在应用程序启动期间由安全性运行时创建的。
要构建授权表，安全性运行时将相应地读取应用程序绑定文件 ibm-application-bnd.xmi 文件或 ibm-application-bnd.xml 文件。

在使用 Security Access Facility (例如 RACF®) 进行授权时访问 EJBROLE 概要文件时，也可以构建授权表。
受支持的配置: 对于 IBM® 扩展和绑定文件，根据您是使用Java EE 5 之前的应用程序或模块，还是使用 Java EE 5 或更高版本的应用程序或模块， .xmi 或 .xml 文件扩展名有所不同。 IBM 扩展或绑定文件名为 ibm-*-ext.xmi 或 ibm-*-bnd.xmi ，其中 * 是扩展或绑定文件的类型，例如 app， application， ejb-jar或 web。存在下列条件：
- 对于使用版本 5 之前的 Java EE 版本的应用程序或模块，文件扩展名必须为 .xmi。
- 对于使用 Java EE 5 或更高版本的应用程序或模块，文件扩展名必须为 .xml。如果应用程序或模块随附 .xmi 文件，那么产品会忽略 .xmi 文件。
但是， Java EE 5 或更高版本的模块可以存在于包含Java EE 5 之前的文件并使用 .xmi 文件扩展名的应用程序中。

ibm-webservices-ext.xmi、ibm-webservices-bnd.xmi、ibm-webservicesclient-bnd.xmi、ibm-webservicesclient-ext.xmi 和 ibm-portlet-ext.xmi 文件继续使用 .xmi 文件扩展名。

使用授权信息以确定调用者是否拥有请求服务必需的特权。您可以采用很多方式存储授权信息。例如，对于每种资源，您可以存储包含用户和用户特权列表的访问控制表。存储信息的另一种方法是将资源列表与每个用户的相应特权关联起来。此列表称为能力列表。

WebSphere® Application Server 使用 Java 2 Platform ， Enterprise Edition (J2EE) 授权模型。在此模型中，授权信息组织如下：

在应用程序汇编期间，将调用方法的许可权授权给一个或多个角色。角色是一组许可权；例如，在银行业务应用程序中，角色可以包括 teller、supervisor、clerk 和其他与行业相关的职位。 teller 角色与运行方法（例如，withdraw 和 deposit 方法）的许可权相关联，这些方法与管理帐户中的现金相关。未授予 teller 角色关闭帐户的许可权；将此许可权授权给 supervisor 角色。应用程序汇编员定义了每个角色的方法许可权的列表。此列表存储在应用程序的部署描述符中。在 Java EE7 和更高版本中，引入了特殊角色名称“**”。此角色表示如果用户已认证，即授予访问权。

J2EE 模型未定义下面这三个特殊主体集：AllAuthenticatedUsers、AllAuthenticatedInTrustedRealms 和 Everyone。特殊主体集是产品定义的一个实体，是在用户注册表以外定义的。此实体一般用于表示注册表中的一类用户或组。

AllAuthenticatedUsers 主体集允许所有已认证的用户访问受保护方法。只要用户能够成功通过认证，就允许用户访问受保护资源。
AllAuthenticatedInTrustedRealms 主体集允许所有已认证外部用户（已绑定到其他领域的用户）访问保护方法。只要用户能够成功通过认证，就允许用户访问受保护资源。
Everyone 主体集允许对受保护资源进行无限制访问。用户不必进行认证就可以访问；此特殊主体集访问受保护方法时就像资源不受保护一样。

避免麻烦: 使用 SAF 配置 WebSphere Application Server 时，将忽略特殊主体集。 SAF 中提供了这些功能。通过在 RACF 中使用 RESTRICTED 属性定义未经认证的用户标识来模拟这些功能。如果在“通用访问权” (UACC) 为“读取”的情况下创建了 EJBROLE 概要文件，那么除了未经认证的用户标识之外，所有已认证的用户都具有访问权。

在应用程序的部署期间，将真实的用户或用户组指定给这些角色。将用户指定给角色时，该用户获取授予该角色的所有方法许可权。

[z/OS] 取决于您的环境，可能存在某些限制。例如，利用 SAF 时，始终会对 SAF 数据库进行检查。如果在对给定角色进行访问检查之前未进行认证，那么使用缺省 SAF 标识来进行检查。除非在 com.ibm.SAF.authorization 属性中配置了有效的缺省用户标识，否则不会授予访问权。

[AIX Solaris HP-UX Linux Windows] [IBM i] 应用程序部署者不需要了解各个方法。通过将角色指定给方法，应用程序汇编员简化了应用程序部署者的作业。部署者使用表示方法的语义分组的角色，而不是使用一组方法。

[z/OS] 管理员负责管理这些角色。

可以将用户指定给多个角色；授予给用户的许可权就是授予给每个角色的许可权的并集。另外，如果认证机制支持用户分组，那么可以将这些组指定给角色。将组指定给角色与将每个单独的用户指定给角色具有相同效果。

部署期间的最佳实践是将组而不是单个用户分配给角色，原因如下:

这样提高了授权检查期间的性能。通常存在的组比用户要少得多。
通过使用组成员资格控制资源访问，提供了更大的灵活性。
支持添加用户和从产品环境外的组中删除用户。首选此操作以将其添加到 WebSphere Application Server 角色并将其除去。停止并重新启动企业应用程序，以使这些更改生效。在生产环境中，此操作具有很强的破坏性。

[z/OS] 在部署期间，最好是将组指定给角色，而不是将各个用户指定给角色。如果正在使用绑定而不是 SAF EJBROLES 进行授权并且需要更改绑定值，那么必须重新启动服务器以获取新的值。如果正在使用 SAF EJBROLES，那么应用程序服务器会自动检测更改。有关更多信息，请参阅 System Authorization Facility for role-based authorization

在运行时， WebSphere Application Server 根据用户的标识信息以及用户到角色的映射来授权入局请求。如果用户属于任何有权运行方法的角色，那么会为请求授权。如果用户不属于任何拥有许可权的角色，那么请求被拒绝。

J2EE 方法代表用于授权的说明性方法，但它也识别您无法说明性处理的所有情况。对于这些情况，提供了按程序确定用户和角色信息的方法。对于企业 Bean ， WebSphere Application Server支持以下两种方法:

getCallerPrincipal：此方法用于检索用户标识信息。
isCallerInRole：此方法用于检查特定角色的用户标识信息。

对于 servlet ， WebSphere Application Server支持以下方法:

getRemoteUser
isUserInRole
getUserPrincipal

这些方法符合企业 Bean 方法的目的。