管理角色和命名服务授权

WebSphere® Application Server 扩展了 Java™ Platform, Enterprise Edition (Java EE) 基于安全角色的访问控制，以保护产品管理和命名子系统。

管理角色

定义了多个管理角色，以提供从管理控制台或称为 wsadmin 的系统管理脚本编制接口执行某些 WebSphere Application Server 管理功能所需的权限。仅当管理安全性处于启用状态时，才会实施授权策略。下表对管理角色作了描述：

表 1. 通过管理控制台和 wsadmin提供的管理角色。
下表列示可以通过管理控制台和 wsadmin 使用的管理角色。
角色	描述
监视器	使用监视员角色的个人或组拥有最少的特权。监视员可以完成下列任务：查看 WebSphere Application Server 配置。查看 Application Server 的当前状态。
配置工具	使用配置员角色的个人或组具有监视员特权以及更改 WebSphere Application Server 配置的能力。配置员可以执行所有日常配置任务。例如，配置员可以完成下列任务：创建资源。映射应用程序服务器。安装和卸载应用程序。部署应用程序。为应用程序指定从用户和组到角色的映射。为应用程序设置 Java 2 安全许可权。定制公共安全互操作性 V2 (CSIv2)、安全认证服务 (SAS) 和安全套接字层 (SSL) 配置。重要信息: 仅在 V 6.0.x 与已在 V 6.1 单元中联合的先前版本服务器之间支持 SAS。
操作员	使用操作员角色的个人或组拥有监视员特权以及更改运行时状态的能力。例如，操作员可以完成下列任务：停止和启动服务器。在管理控制台中监视服务器状态。
管理员	使用管理员角色的个人或组拥有操作员和配置员特权以及单独授予管理员角色的特权。例如，管理员可以完成下列任务：修改服务器用户标识和密码。配置认证和授权机制。启用或禁用管理安全性。注: 在 WebSphere Application Server的前发行版中，启用管理安全性选项称为启用全局安全性选项。使用使用 Java 2 安全性来限制应用程序对本地资源的访问选项来实施 Java 2 安全性。更改轻量级第三方认证 (LTPA) 密码并生成密钥。在联合存储库配置中创建、更新或删除用户。在联合存储库配置中创建、更新或删除组。注：管理员不能将用户和组映射到管理员角色。有关如何向未被分配 WebSphere Application Server 管理员角色的用户分配联合存储库管理权限的信息，请参阅主题提供安全性中的主题将用户和组映射到角色以分配联合存储库管理权限。
Adminsecuritymanager	只有被授予此角色的用户才能将用户映射到管理角色。另外，当使用细颗粒度管理安全性时，只有被授予此角色的用户才能管理授权组。请参阅管理角色以获取更多信息。
部署员	被授予此角色的用户可以在应用程序上执行配置操作和运行时操作。
审计机构	被授予此角色的用户可以查看和修改安全性审计子系统的配置设置。例如，具有审计员角色的用户可以完成下列任务：启用和禁用安全性审计子系统。选择要与事件工厂插件点配合使用的事件工厂实现。选择并配置服务提供者或发射器。或两者都将与服务提供者插件点配合使用。设置审计策略，此策略描述应用程序服务器在遇到与安全性审计子系统相关的错误时的行为。定义所要审计的安全性事件。审计员角色包括监视员角色。这使得审计员可以查看其余安全配置，但是不能更改。

表 2. 通过管理控制台提供的其他管理角色。
下表列示另一个可通过管理控制台使用的管理角色。
角色	描述
iscadmins	此角色仅适用于管理控制台用户，而不适用于 wsadmin 用户。被授予此角色的用户拥有管理员特权，能够管理联合存储库中的用户和组。例如，iscadmins 角色的用户可以完成下列任务：在联合存储库配置中创建、更新或删除用户。在联合存储库配置中创建、更新或删除组。

表 3. 通过 wsadmin提供的其他管理角色。
下表列示另一个可通过管理控制台使用的管理角色。
角色	描述
部署员	此角色仅适用于 wsadmin 用户，而不适用于管理控制台用户。被授予此角色的用户可以对应用程序执行配置操作和运行时操作。

启用管理安全性后，将实施基于管理子系统角色的访问控制。管理子系统包括安全服务器，管理控制台， wsadmin 脚本编制工具和所有 Java 管理扩展 (JMX) MBean。当启用管理安全性时，管理控制台和管理脚本编制工具都需要用户提供必需的认证数据。而且，设计了管理控制台，因此可以根据用户具有的安全角色调整页面上显示的控制功能。例如，仅具有监视员角色的用户只能查看非敏感的配置数据。具有操作员角色的用户可以更改系统状态。

当您更改注册表（例如，从联合存储库更改为 LDAP）时，请务必移除与先前为控制台用户和控制台组配置的注册表有关的信息。

[z/OS] "WebSphere Application Server for z/OS®安全定制对话框会使管理子系统接受所有已启动的 "WebSphere Application Server系统任务（如控制器、仆从等）的 MVS 身份作为 "WebSphere管理员和已配置的管理员身份。如果指定了联合存储库、独立轻量级目录访问协议 (LDAP) 注册表或独立定制注册表，那么会将已配置的服务器标识用于系统所运行的工作，而不用于由已启动的任务标识运行的工作。

com.ibm.security.SAF.authorization 设置的值可以控制是使用 SAF EJBROLE 概要文件还是控制台设置来控制对管理概要文件的访问，而不是使用控制台用户来控制该访问。当 com.ibm.security.SAF.authorization 属性设置为 true 时，将选择 SAF 授权方法并使用 SAF EJBROLE 概要文件来控制对管理角色的访问。

注: 使用系统授权工具 (SAF) 授权时，将忽略控制台用户和控制台组中的任何值。

如果使用 WebSphere Application Server 授权而不是 SAF 授权来限制对 Java Platform, Enterprise Edition (Java EE) 角色的访问， WebSphere Application Server for z/OS 会自动将在启用管理安全性时指定的服务器身份映射到管理角色。启用管理安全性后， WebSphere Application Server for z/OS 将在活动用户注册表配置下定义的服务器身份下运行。尽管它不会在管理控制台和其他工具中显示，但特殊的服务器主体集将映射至管理员角色。

在服务器身份下运行的 WebSphere Application Server 运行时代码需要对某些运行时操作进行授权。可以显式输入服务器标识和密码，也可以自动生成标识。在前一种方法中，服务器标识是注册表中的有效用户。在后一种方法中，将使用 internalServerId 功能部件来自动生成服务器标识。每个用户注册表的配置面板都允许您进行此选择。对于 internalServerId，在主管理用户名字段中输入管理员标识或 adminID。此 adminID 是注册表中的一个有效用户，并且此标识的密码不是必需的，也不会保存在配置中。
如果没有将显式用户或组指定为管理角色，那么在使用 internalServerId 功能部件来执行管理操作时可以使用服务器标识或 adminID 登录管理控制台或 wsadmin 脚本编制工具，以及指定其他用户或组作为管理角色。之所以可以这样做，是因为会自动对 adminsecuritymanager 角色指定服务器标识（或 adminID）。只有与 adminsecuritymanager 相关联的用户/组才能管理所有管理角色的用户/组。一旦您使用服务器标识（或 adminID）来登录，管理安全策略就允许您执行以下操作：
- 更改服务器标识和服务器密码
- 启用或禁用 WebSphere Application Server 管理安全性
- 使用 使用 Java 2 安全性来限制应用程序对本地资源的访问 选项来实施 Java 2 安全性。
- 更改 LTPA 密码或生成密钥
启用管理安全性以供管理使用时指定的服务器身份不需要特殊配置，因为服务器身份会自动映射到管理员角色。您可以在 WebSphere Application Server 管理控制台中向管理角色添加用户和组，也可以从管理角色中除去用户和组。但是，您必须重新启动服务器以使更改生效。最好的做法是将组（而不是特定用户）映射至管理角色，原因这种做法更加灵活并且更容易进行管理。通过将组映射到管理角色，可以在 WebSphere Application Server 外部向组添加用户或从组中除去用户，并且不需要重新启动服务器即可使更改生效。

[AIX Solaris HP-UX Linux Windows] [IBM i] 启用管理安全性后， WebSphere Application Server 将在活动用户注册表配置下定义的服务器身份下运行。尽管它不会在管理控制台和其他工具中显示，但特殊的服务器主体集将映射至管理员角色。在服务器身份下运行的 WebSphere Application Server 运行时代码需要对运行时操作进行授权。如果没有将其他用户指定为管理角色，那么您可以使用服务器标识登录管理控制台或 wsadmin 脚本编制工具来执行管理操作和指定其他用户或组为管理角色。因为缺省情况下服务器标识指定给管理角色，所以管理安全策略需要管理角色来执行以下操作：

更改服务器标识和服务器密码
启用或禁用 WebSphere Application Server管理安全性
使用 使用 Java 2 安全性来限制应用程序对本地资源的访问 选项来实施 Java 2 安全性。
更改 LTPA 密码或生成密钥
指定用户和组为管理角色

WebSphere Application Server 及其后续发行版的 6.1 发行版需要以下内容:

一个与服务器用户标识不同的管理用户来提高管理操作的可审计性。用户名指定在本地操作系统中定义的拥有管理特权的用户。
将服务器标识与管理用户标识区分开以提高审计性。服务器用户标识用于认证服务器到服务器通信。
内部服务器标识允许自动生成用户标识以进行服务器到服务器认证。仅对于 V6.1 或更高版本的节点，自动生成服务器标识才提供提高单元的可审计性。在WebSphere Application Server 6.1版本中，您可以保存内部生成的服务器 ID，因为安全WebSphereCommon Configuration Model (WCCM) 模型包含一个新标签internalServerId。除了在混合单元环境中以外，在配置安全性期间，不需要指定服务器用户标识和密码。因为服务器密码并不是像版本 6.1 之前的发行版中那样显示，所以内部生成的服务器标识会向服务器环境添加更高的保护级别。但是，要保持向后兼容性，如果使用较早版本的 WebSphere Application Server，那么必须指定服务器用户标识。
启用安全性时，可以为命名角色指定一个或多个用户和组。有关更多信息，请参阅将用户分配给命名角色。但是在指定用户为命名角色前，配置活动的用户注册表。用户和组的验证取决于活动的用户注册表。有关更多信息，请参阅配置用户注册表。
能够将特殊主体集映射至管理角色。特殊主体集是特定用户类的泛化关系。 AllAuthenticated 或 AllAuhenticatedInTrustedRealms（涉及跨领域时）特殊主体集表示对管理角色的访问检查确保发出请求的用户至少已经过认证。 Everyone 特殊主体集意味着任何人（已经过认证的或未经过认证的）都可以执行此操作，就像未启用安全性一样。

命名服务授权

CosNaming 安全性对 CosNaming 功能提供增强的细颗粒度安全性控制。 CosNaming 功能在 CosNaming 服务器 (例如 WebSphere Application Server) 上可用。这些函数会影响 WebSphere Application Server 名称空间的内容。通常，客户机程序可以采用两种方法来调用 CosNaming。第一个方法是通过 Java 命名和目录接口 (JNDI) 调用。第二种方法是使用公共对象请求代理体系结构 (CORBA) 客户机来直接调用 CosNaming 方法。

引入了四个安全角色：

CosNamingRead
CosNamingWrite
CosNamingCreate
CosNamingDelete

这些角色具有从低到高的权限级别：

CosNamingRead: 例如，可以使用 JNDI 查找方法来查询 WebSphere Application Server 名称空间。特殊主体集 Everyone 是此角色的缺省策略。
CosNamingWrite: 可以执行诸如 JNDI 绑定、重新绑定或取消绑定之类的写操作以及 CosNamingRead 操作。作为一种缺省策略，没有为主体集指定此角色。
CosNamingCreate: 可以通过诸如 JNDI createSubcontext 和 CosNamingWrite 等操作在名称空间中创建新对象。作为一种缺省策略，没有为主体集指定此角色。
CosNamingDelete: 可以使用 JNDI destroySubcontext 方法和 CosNamingCreate 操作之类的方法和操作来破坏名称空间中的对象。作为一种缺省策略，没有为主体集指定此角色。

[z/OS] 使用 WebSphere Application Server for z/OS配置本地操作系统注册表时，需要考虑一些其他因素。有关更多信息，请参阅选择注册表或存储库和配置本地操作系统注册表。如果指定联合存储库，独立 LDAP 注册表或独立定制注册表，那么必须通过从控制台组中删除预先配置的 WebSphere Application Server 配置组和管理员身份并删除控制台用户来除去本地操作系统定制。

缺省情况下，会将“Server”特殊主体集指定给所有四个 CosNaming 角色。服务器特殊主体集提供在服务器身份下运行的 WebSphere Application Server 进程，以访问所有 CosNaming 操作。不会显示 Server 特殊主体集，也不能通过管理控制台或其他管理工具对其进行修改。

启用管理安全性以供管理使用时指定的服务器身份不需要特殊配置，因为服务器身份会自动映射到管理员角色。

[AIX Solaris HP-UX Linux Windows] [IBM i] 可以随时从 WebSphere Application Server 管理控制台将用户，组或特殊主体集 AllAuthenticated 和 Everyone 添加到命名角色或从命名角色中除去这些用户，组或特殊主体集。但是，要求重新启动服务器才能使更改生效。

[z/OS] 在启用管理安全性以用于管理时，不需要配置来启用服务器身份 (如所指定) ，因为服务器身份会自动映射到管理员角色。可以随时从 WebSphere Application Server 管理控制台将用户，组或特殊主体集 AllAuthenticated 和 Everyone 添加到命名角色或从命名角色中除去他们。但是，要求重新启动服务器才能使更改生效。当选择“SAF 授权”时，不需要重新启动服务器来授权其他用户或组。

最好的做法是将组或特殊主体集中的一个主题（而不是特定用户）映射至命名角色，因为从长远来看，这种做法更加灵活并且更容易进行管理。通过将组映射到命名角色，可以在 WebSphere Application Server 外部将用户添加到组或从组中除去用户，并且不需要重新启动服务器即可使更改生效。

仅当启用了管理安全性时，才会实施 CosNaming 授权策略。启用管理安全性时，如果尝试执行 CosNaming 操作而未正确分配角色，那么会生成 org.omg.CORBA.NO_PERMISSION 来自 CosNaming 服务器的异常。

[AIX Solaris HP-UX Linux Windows] [IBM i] 每个 CosNaming 函数仅分配给一个角色。因此，被指定 CosNamingCreate 角色的用户不能查询名称空间，除非他们也被指定 CosNamingRead。并且在多数情况下，需要为一个创建程序指定三个角色：CosNamingRead、CosNamingWrite 和 CosNamingCreate。为创建程序示例指定的 CosNamingRead 和 CosNamingWrite 角色包含在 CosNamingCreate 角色中。在大多数情况下， WebSphere Application Server 管理员在从先前的用户或组移至此发行版时，不必更改每个用户或组的角色分配。

尽管可以通过更改缺省策略来严格限制对名称空间的访问，但是在运行时会发生意外的 org.omg.CORBA.NO_PERMISSION 异常。通常， Java EE 应用程序访问名称空间，它们使用的身份是在访问 Java EE 应用程序时向 WebSphere Application Server 认证的用户的身份。除非 Java EE 应用程序提供程序明确传达期望的命名角色，否则请在更改缺省命名授权策略时谨慎操作。