管理角色和命名服务授权
WebSphere® Application Server 扩展了 Java™ Platform, Enterprise Edition (Java EE) 基于安全角色的访问控制以保护产品管理和命名子系统。
管理角色
定义了许多管理角色,以提供从管 理控制台或称为 wsadmin 的系统管理脚本编制接口执行某些 WebSphere Application Server 管理功能所需 要的权限级别。仅当启用了管理安全性时才强制执行授权策略。下表对管理角色作了描述:
角色 | 描述 |
---|---|
监视员 | 使用监视员角色的个人或组拥有最少的特权。监视员可以完成下列任务:
|
配置员 | 使用配置员角色的个人或组拥有监视员特权以及更改 WebSphere Application Server 配置的能力。配置员可以执行所有日常配置任务。例如,配置员可以完成下列任务:
|
操作员 | 使用操作员角色的个人或组拥有监视员特权以及更改运行时状态的能力。例如,操作员可以完成下列任务:
|
管理员 | 使用管理员角色的个人或组拥有操作员和配置员特权以及单独授予管理员角色的特权。例如,管理员可以完成下列任务:
注:
管理员不能将用户和组映射至管理员角色。 有关如何向未分配有 WebSphere Application Server 管理员角色的用户分配联合存储库管理权限的信息,请参阅《提供安全性》主题中的《将用户和组映射到各角色以分配联合存储库管理权限》主题。 |
Adminsecuritymanager | 只有被授予此角色的用户才能将用户映射至管理角色。并且,在使用细颗粒度管理安全性时,只有被授予此角色的用户才可以管理授权组。请参阅管理角色,以了解更多信息。 |
部署者 | 被授予此角色的用户可以对应用程序执行配置操作和运行时操作。 |
审计员 | 被授予此角色的用户可以查看和修改安全性审计子系统的配置设置。例如,具有审计员角色的用户可以完成下列任务:
|
角色 | 描述 |
---|---|
iscadmins | 此角色仅适用于管理控制台用户,而不适用于 wsadmin 用户。被授予此角色的用户拥有管理员特权,能够管理联合存储库中的用户和组。例如,iscadmins 角色的用户可以完成下列任务:
|
角色 | 描述 |
---|---|
部署者 | 此角色仅适用于 wsadmin 用户,而不适用于管理控制台用户。被授予此角色的用户可以对应用程序执行配置操作和运行时操作。 |
当启用管理安全性时,执行基于管理子系统角色的访问控制。管理子系统包括安全性服务器、管理控制台、wsadmin 脚本编制工具和所有 Java 管理扩展 (JMX) MBean。当启用管理安全性时,管理控制台和管理脚本编制工具都需要用户提供必需的认证数据。而且,设计了管理控制台,因此可以根据用户具有的安全角色调整页面上显示的控制功能。例如,仅具有监视员角色的用户只能查看非敏感的配置数据。具有操作员角色的用户可以更改系统状态。
当您更改注册表(例如,从联合存储库更改为 LDAP)时,请务必移除与先前为控制台用户和控制台组配置的注册表有关的信息。
WebSphere Application Server for z/OS® 安全性定制对话指导管理子系统接受所有已启动
WebSphere Application Server 系统任务(例如,控制器和服务方等等)的
MVS™ 标识作为 WebSphere 管理员和已配置的管理员标识。如果指定了联合存储库、独立轻量级目录访问协议 (LDAP) 注册表或独立定制注册表,那么会将已配置的服务器标识用于系统所运行的工作,而不用于由已启动的任务标识运行的工作。
![[z/OS]](../images/ngzos.gif)
![[z/OS]](../images/ngzos.gif)
- 以服务器标识运行的 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 外部将用户添加到组或从组中移除用户,并且不需要重新启动服务器就能使更改生效。
当管理安全性处于启用状态时,WebSphere Application Server 将以活动用户注册表配置中定义的服务器标识运行。尽管它不会在管理控制台和其他工具中显示,但特殊的服务器主体集将映射至管理员角色。以服务器标识运行的
WebSphere Application Server 运行时代码需要执行运行时操作的权限。如果没有将其他用户指定为管理角色,那么您可以使用服务器标识登录到管理控制台或 wsadmin 脚本编制工具来执行管理操作和指定其他用户或组为管理角色。因为缺省情况下服务器标识指定给管理角色,所以管理安全策略需要管理角色来执行以下操作:
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
- 更改服务器标识和服务器密码
- 启用或禁用 WebSphere Application Server 管理安全性
- 通过使用 Java 2 安全性来限制应用程序对本地资源的访问选项来强制执行 Java 2 安全性。
- 更改 LTPA 密码或生成密钥
- 指定用户和组为管理角色
- 一个与服务器用户标识不同的管理用户来提高管理操作的可审计性。用户名指定在本地操作系统中定义的拥有管理特权的用户。
- 将服务器标识与管理用户标识区分开以提高审计性。服务器用户标识用于认证服务器到服务器通信。
- 内部服务器标识允许自动生成用户标识以进行服务器到服务器认证。仅对于 V6.1 或更高版本的节点,自动生成服务器标识才提供提高单元的可审计性。在
WebSphere Application Server V6.1 发行版中,由于安全性
WebSphere 公共配置模型 (WCCM) 模型包含新标记 internalServerId,所以可以保存内部生成的服务器标识。除了在混合单元环境中以外,在配置安全性期间,不需要指定服务器用户标识和密码。因为服务器密码并不是像版本 6.1 之前的发行版中那样显示,所以内部生成的服务器标识会向服务器环境添加更高的保护级别。但是,如果使用较低版本的
WebSphere Application Server,为了保持向后兼容,就必须指定服务器用户标识。
启用安全性时,可以为命名角色指定一个或多个用户和组。有关更多信息,请参阅指定用户为命名角色。但是在指定用户为命名角色前,配置活动的用户注册表。用户和组的验证取决于活动的用户注册表。有关更多信息,请参阅配置用户注册表。
- 能够将特殊主体集映射至管理角色。特殊主体集是用户特殊类的普遍化。AllAuthenticated 或 AllAuhenticatedInTrustedRealms(涉及跨领域时)特殊主体集表示对管理角色的访问检查确保发出请求的用户至少已经过认证。Everyone 特殊主体集意味着任何人(已经过认证的或未经过认证的)都可以执行此操作,就像未启用安全性一样。
命名服务授权
CosNaming 安全性对 CosNaming 功能提供增强的细颗粒度安全性控制。CosNaming 服务器(如 WebSphere Application Server)上提供 CosNaming 功能。这些功能会影响 WebSphere Application Server 名称空间的内容。通常,客户机程序可以采用两种方法来调用 CosNaming。第一种方法是通过 Java 命名和目录接口 (JNDI) 调用来进行调用。第二种方法是使用公共对象请求代理体系结构 (CORBA) 客户机来直接调用 CosNaming 方法。
- CosNamingRead
- CosNamingWrite
- CosNamingCreate
- CosNamingDelete
- CosNamingRead
- 可以使用诸如 JNDI 查询方法来查询 WebSphere Application Server 名称空间。特殊主体集“每个人”是此角色的缺省策略。
- CosNamingWrite
- 可以执行诸如 JNDI 绑定、重新绑定或取消绑定之类的写操作以及 CosNamingRead 操作。作为一种缺省策略,没有为主体集指定此角色。
- CosNamingCreate
- 可以通过诸如 JNDI createSubcontext 和 CosNamingWrite 等操作在名称空间中创建新对象。作为一种缺省策略,没有为主体集指定此角色。
- CosNamingDelete
- 可以使用 JNDI destroySubcontext 方法和 CosNamingCreate 操作之类的方法和操作来破坏名称空间中的对象。作为一种缺省策略,没有为主体集指定此角色。
当使用
WebSphere Application Server for z/OS 来配置本地操作系统注册表时,需要进一步考虑各种因素。请参阅选择注册表或存储库和配置本地操作系统注册表,以了解更多信息。如果指定联合存储库、独立 LDAP 注册表或独立定制注册表,那么必须通过从控制台组中删除预先配置的
WebSphere Application Server 配置组和管理员身份来移除本地操作系统定制,并且必须删除控制台用户。
缺省情况下,会将“Server”特殊主体集指定给所有四个 CosNaming 角色。Server 特殊主体集提供 WebSphere Application Server 进程(此进程以服务器标识运行)来访问所有 CosNaming 操作。不会显示 Server 特殊主体集,也不能通过管理控制台或其他管理工具对其进行修改。
因为服务器标识会自动映射至管理员角色,所以在启用管理安全性进行管理时,不需要特殊配置来像指定的那样启 用服务器标识。
可以随时从 WebSphere Application Server
的管理控制台中将用户、组或特殊主体集“所有已认证”和“每个人”添加到命名角色或从中移除他们。但是,要使更改生效,需要重新启动服务器。
因为服务器标识会自动映射至管理员角色,所以在启用管理安全性以进行管理时,不需要配置来(像指定的那样)启用服务器标识。可以随时从 WebSphere Application Server
的管理控制台中将用户、组或特殊主体集“所有已认证”和“每个人”添加到命名角色或从中移除他们。但是,要使更改生效,需要重新启动服务器。当选择“SAF 授权”时,不需要重新启动服务器来授权其他用户或组。
最好的做法是将组或特殊主体集中的一个主题(而不是特定用户)映射至命名角色,因为从长远来看,这种做法更加灵活并且更容易进行管理。通过将组映射至命名角色,可以在 WebSphere Application Server 外部将用户添加到组或从组中移除用户,并且不需要重新启动服务器就能使更改生效。
仅当启用了管理安全性时才会强制执行 CosNaming 授权策略。当启用了管理安全性时,在没有指定正确角色的情况下尝试执行 CosNaming 操作将导致 CosNaming 服务器产生 org.omg.CORBA.NO_PERMISSION 异常。
每项 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 应用程序供应商明确指出期望的命名角色,否则在更改缺省命名授权策略时应谨慎。