[z/OS]

将系统授权工具用于基于角色的授权

当分配角色时,有三个选项: (1) WebSphere® Application Server 授权,其中授权管理是在 WebSphere Administration 中通过使用管理控制台的“安全角色到用户/组映射”面板来执行的。(2) 用于基于角色的授权的系统授权工具 (SAF)(仅适用于 WebSphere Authorization Facility for z/OS 的选项),它将 SAF 授权用于 Java 2 Platform Enterprise Edition (J2EE) 角色。(3) 使用可插入 JACC 接口的外部授权提供程序。当 WebSphere Application Server 配置为使用 SAF 授权时,授权管理是通过使用 SAF 管理设施执行的,并且会忽略 WebSphere Administration 中的 J2EE 角色管理的用户或组。将使用 EJBROLE 的 SAF 类(例如,使用 RACF® EJBROLE 概要文件)来控制在 EJB 和 Web 应用程序(包括 WebSphere Application Server 管理控制台应用程序)中客户机对 Java™ 2 Platform, Enterprise Edition (J2EE) 角色的访问。

使用 SAF 授权时的重要注意事项: 选择 SAF 进行授权时,需要考虑对后续授权操作的若干功能影响:
  • 如果在管理控制台中选择了 SAF 授权,那么它将覆盖任何其他授权选项(如 Tivoli Access Manager 授权)。请参阅 控件总结,以了解更多信息。
  • 启用 SAF 授权后,任何级别的授权都始终由操作系统的安全管理器(RACF 或同等产品)执行。也就是说,需要使用安全管理器 (RACF) 用户标识来认证用户,或者需要使用 SAF 映射模块。请参阅 操作系统级别和应用程序级别的系统授权工具注意事项,以了解更多信息。
  • 当系统定制期间选择了 SAF 授权时,所有管理角色的管理 EJBROLE 概要文件都由 RACF 作业来定义(这些作业是使用“定制”对话框生成的),并且可以将 SAF 授权用作所有用户注册表的授权机制。请参阅 当使用本地操作系统注册表时,控制对控制台用户的访问,以了解更多信息。
  • 配置 SAF 授权时,属性 com.ibm.security.SAF.authorization 将设置为 true,并且将使用 SAF EJBROLE 概要文件来控制对管理角色的访问。请参阅授予管理角色访问权,以获取有关授予对管理角色的访问的更多信息。
  • 启用 SAF 授权后,将忽略控制台用户和控制台组中的任何值。将忽略管理控制台中的“将安全角色映射到用户/组”功能面板。请参阅管理角色和命名服务授权以了解更多信息。
  • 因为“Everyone”和“All Authenticated”在 RACF 中进行管理,所以将被忽略。请参阅操作系统级别和应用程序级别的系统授权工具注意事项以及从安全角色到用户或组的映射,以了解更多信息。
  • 启用 SAF 授权时,将使用 SAF EJBROLE 概要文件来控制对 CosNaming 功能的访问。在“定制”对话框中设置安全域时,将通过定制作业来定义 CosNaming 角色。请参阅使用“SAF 授权”来控制对命名角色的访问时的特殊注意事项,以获取有关 CosNaming 功能和 SAF 授权以及引用管理角色和命名服务授权的更多信息。
  • 当启用 SAF 授权时,使用 SAF EJBROLE 概要文件来对 J2EE 角色授权。对于非本地操作系统注册表,必须存在身份映射,才能将 WebSphere Application Server 身份映射到 SAF 身份。请参阅当使用本地操作系统注册表时,控制对控制台用户的访问,以了解更多信息。
  • 对 J2EE 角色进行 SAF 授权是独立应用程序部署过程的任务。请参阅为用户和组指定角色以了解更多信息。
  • EJBROLE 类应已经 RACLIST。如果 EJBROLE 类尚未 RACLIST,那么必须重新启动应用程序服务器,才能取得对 EJBROLE 类中的概要文件所做的更改。
  • Servlet 3.1 规范新定义了角色名 **,此角色名将为所有已认证用户授予访问权。缺省情况下,授权决策由 SAF 制定。
  • com.ibm.websphere.security.delegateStarStarRoleAuthorization 定制属性定义当角色名为 ** 时,安全代码是否会为所有已认证用户授予访问权。
    • true - 安全代码将授予访问权而不与可插入授权表交互。
    • false - 安全代码将决策委托给可插入授权表。这是缺省值。
支持的配置 支持的配置: 当使用 SAF 授权时,要确保在 SAF 中对用户或组成员资格所做的所有更改都立即生效,请为所修改的用户调用 purgeUserFromAuthCache SecurityAdmin MBean 方法。否则,更改将在高速缓存定期刷新时生效。或者,可以重新启动服务器。sptcfg

启用 SAF 授权时,将使用 SAF EJBROLE 概要文件来对 Java EE 角色授权。对于非本地操作系统注册表,必须存在身份映射,才能将 WebSphere Application Server 身份映射到 SAF 身份。

要启用 SAF 授权,请参阅z/OS 系统授权工具授权,以了解更多信息。

定义 EJBROLES 属于应用程序部署过程的一部分。如果用户标识对已定义的 EJBROLE 概要文件(它与应用程序定义的 Java EE 角色相对应)至少具有读访问权,那么认为该用户标识具有角色。(不要被名称 EJBROLE 搞糊涂。它用于企业 Bean 和 Web 应用程序中的 Java EE 角色。)

当应用程序部署程序在组件的部署描述符中使用角色时,角色名称必须与 EJBROLE 概要文件的名称完全相同。安全性管理员定义 EJBROLE 概要文件并允许 SAF 用户或组访问概要文件。为了认为用户是合格的角色,用户必须有对 EJBROLE 概要文件的读访问权或必须连接到具有读访问权的 SAF 组。

当选择 SAF 授权时,SAF 概要文件前缀的规范(先前称为 z/OS 安全域)会影响 WebSphere Application Server for z/OS 系统资源使用的特定 EJBROLE 概要文件。当定义了 SAF 前缀时,WebSphere Application Server for z/OS 运行时的 Java EE 应用程序 EJBROLE 概要文件将此属性的值作为前缀。这允许您在同一综合系统 (sysplex) 的不同单元上部署同一应用程序,但根据需要具有不同的用户到角色映射。

例如,您的应用程序有两个 Java EE 角色名称:juniorTellersseniorTellers。这些是混合的案例角色。在 SAF 注册表中,您有一个称为 JTELLERSTELLER 的 MVS 组,还有一个称为 BANKADM 的 MVS 用户标识。访问 juniorTellers 角色时需要 JTELLER 组,访问 seniorTellers 角色时需要 STELLER 组。访问两个角色需要 BANKADM 用户标识。

您有两个单元,这两个单元都定义为使用 SAF 概要文件前缀。这些前缀分别是 PRODCELLTESTCELLTEST1 用户标识应该对这两个角色都有访问权,但只在测试环境 TESTCELL 中。

如果要在两个单元中部署同一应用程序,那么必须按如下所示使用 RACF(或等价的安全性子系统)定义不同的概要文件。

如果将 RACF 用作安全服务器,请通过发出以下命令来将它启用:
/* EJBROLE 类必须处于活动状态,此步骤才有定制对话执行  */
SETROPTS CLASSACT(EJBROLE)

/* first define the roles in RACF */
RDEFINE EJBROLE PRODCELL.juniorTellers UACC(NONE)
RDEFINE EJBROLE PRODCELL.seniorTellers UACC(NONE)

RDEFINE EJBROLE TESTCELL.juniorTellers UACC(NONE)
RDEFINE EJBROLE TESTCELL.seniorTellers UACC(NONE)

/* 允许适用于各种角色的用户和组 */
PERMIT PRODCELL.juniorTellers CLASS(EJBROLE)  ID(JTELLER BANKADM) ACCESS(READ)
PERMIT PRODCELL.seniorTellers CLASS(EJBROLE)  ID(STELLER BANKADM) ACCESS(READ)

PERMIT TESTCELL.juniorTellers CLASS(EJBROLE)  ID(TEST1) ACCESS(READ)
PERMIT TESTCELL.seniorTellers CLASS(EJBROLE)  ID(TEST1) ACCESS(READ)

/* refresh the EJBROLE class in RACF *
SETROPTS RACLIST(EJBROLE) REFRESH"     

对 EJBROLE 分组 (GEJBROLE)

SAF 接口还支持 EJBROLE 类的分组类。此分组类称为 GEJBROLE。当您需要赋予多个角色的相同用户或组访问权时它特别有用。

GEJBROLE 分组类提供了其他 Java EE 服务器本机上没有的能力。使用 Java EE 安全模型时,如果有几个组件或应用程序对相似的功能使用不同的角色名(例如,对于管理功能使用 Hire、Promote 或 GrantPayraise),那么有以下几个选项可供选择:
  • 调整应用程序部署描述符,以使它们符合在企业中所定义的角色(例如,经理)。此过程将花费很长时间并且特别容易出错,这是因为每次更改或重新安装应用程序时可能就需要重新调整部署描述符。
  • 为应用程序需要的每个角色定义 EJBROLE 概要文件。然后允许用户和组访问这些角色。管理员可能要大量执行此过程,这是因为相同的用户和组可能对含义相似的几个不同的概要文件具有许可权。
  • 使用分组类来避免其他两个选项的最坏情况。仍必须为应用程序需要的每个角色定义 EJBROLE 概要文件。而不允许所有相同的用户和组使用新的概要文件(例如,supervisors)、在分组类中创建概要文件,并将所有新的 EJBROLE 概要文件添加到该概要文件中。可以在一个位置(例如,supervisors 概要文件)为需要访问这些角色的每个用户和组授予许可权。可以通过将现有 EJBROLE 概要文件 (Managers) 添加至分组类概要文件 (Supervisors) 来进一步避免执行管理工作。
实现 GEJBROLES 时的注意事项:
  • 计划 RACF 类 GEJBROLE 中的组织角色概要文件。
  • 通过允许用户组访问 GEJBROLE 概要文件来创建访问列表,然后将角色添加到 GEJBROLE 概要文件。
  • 仅含一个 EJBROLE 的 GEJBROLE 是正确的。
  • 不允许混合使用 EJBROLE 和 GEJBROLE 进行用户对角色的访问。
  • 如果可能,仅允许用户对 GEJBROLE 概要文件的访问。
  • 通常 GEJBROLE 的使用优先于 EJBROLE。

指示主题类型的图标 概念主题



时间戳记图标 最近一次更新时间: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=csec_ejbroleandg
文件名:csec_ejbroleandg.html