管理角色和命名服务授权

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）时，请务必移除与先前为控制台用户和控制台组配置的注册表有关的信息。

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

[AIX Solaris HP-UX Linux Windows][IBM i]
  • 更改服务器标识和服务器密码
  • 启用或禁用 WebSphere Application Server管理安全性
  • 使用 使用 Java 2 安全性来限制应用程序对本地资源的访问 选项来实施 Java 2 安全性。
  • 更改 LTPA 密码或生成密钥
  • 指定用户和组为管理角色
WebSphere Application Server 及其后续发行版的 6.1 发行版需要以下内容:
  • 一个与服务器用户标识不同的管理用户来提高管理操作的可审计性。 用户名指定在本地操作系统中定义的拥有管理特权的用户。
  • 将服务器标识与管理用户标识区分开以提高审计性。 服务器用户标识用于认证服务器到服务器通信。
  • 内部服务器标识允许自动生成用户标识以进行服务器到服务器认证。 仅对于 V6.1 或更高版本的节点，自动生成服务器标识才提供提高单元的可审计性。 在 6.1 版本的 WebSphere Application Server 中，您可以保存内部生成的服务器 ID，因为安全 WebSphere 通用配置模型 (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 操作之类的方法和操作来破坏名称空间中的对象。 作为一种缺省策略，没有为主体集指定此角色。

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

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

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

最好的做法是将组或特殊主体集中的一个主题（而不是特定用户）映射至命名角色，因为从长远来看，这种做法更加灵活并且更容易进行管理。 通过将组映射到命名角色，可以在 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 应用程序提供程序明确传达期望的命名角色，否则请在更改缺省命名授权策略时谨慎操作。