细颗粒度管理安全性

在 WebSphere® Application Server V6.1 之前的发行版中，被授予管理角色的用户可以管理单元下的所有资源。 WebSphere Application Server 现在更细颗粒度，这意味着可以向每个资源的每个用户授予访问权。

例如，可以只为用户授予对某种资源特定实例（应用程序、应用程序服务器或节点）的配置程序访问权。用户将不能访问分配给他们的资源以外的任何其他资源。现在，管理角色可以管理每个资源而不是整个单元。但是，为了与较低版本保持兼容，还是提供了一个单元范围的授权组。为单元范围的授权组中的管理角色指定的用户仍然可以访问单元中的所有资源。

注: 将从资源映射中过滤掉混合单元环境中 WebSphere Application Server V6.1 之前的节点。

为了获得这种基于实例的安全性或细颗粒度的安全性，将需要相同特权的所有资源放入一个称为“管理授权组”或“授权组”的组中。通过为用户指定必需的管理角色，可以为其授予对授权组的访问权。

还可以在单服务器环境中使用细颗粒度管理安全性。可以将单个服务器中的各种应用程序分组并放入不同的授权组中。因此，对于不同的应用程序具有不同的授权约束。注意，在单一服务器环境中，服务器本身不能属于任何授权组。

可通过 wsadmin 脚本和管理控制台在单元级别将用户和组指定到 adminsecuritymanager 角色。通过使用 adminsecuritymanager 角色，可以对用户和组指定管理用户角色和管理组角色。

在使用细颗粒度的管理安全性时，被授予 adminsecuritymanager 角色的用户可以管理授权组。请参阅管理角色和命名服务授权，以获取所有管理角色的详细说明。

管理员不能将管理用户角色和管理组角色（其中包括 adminsecuritymanager 角色）指定给用户和组。有关更多详细信息，请参阅管理角色。

可以使用一些管理安全性命令来创建授权组、将资源映射至授权组以及对用户指定授权组中的管理角色。以下是使用 wsadmin 的一些示例：

创建新的授权组：

$AdminTask createAuthorizationGroup {-authorizationGroupName authGroup1}

删除授权组：

$AdminTask deleteAuthorizationGroup {-authorizationGroupName groupName}

将资源添加至授权组：

$AdminTask addResourceToAuthorizationGroup
{-authorizationGroupName groupName -resourceName Application=app1}

从授权组中除去资源：

$AdminTask removeResourceFromAuthorizationGroup 
{-authorizationGroupName groupName -resourceName Application=app1}

将用户标识添加至授权组中的角色：

$AdminTask mapUsersToAdminRole {-authorizationGroupName groupName
-roleName administrator -userids user1}

将组标识添加至授权组中的角色：

$AdminTask mapGroupsToAdminRole {-authorizationGroupName groupName
-roleName administrator -groupids group1}

从授权组中的角色中除去用户标识：

AdminTask removeUsersFromAdminRole {-authorizationGroupName
groupName -roleName administrator -userids user1}

从授权组中的角色中除去组标识：

$AdminTask removeGroupsFromAdminRole {-authorizationGroupName
groupName -roleName administrator -groupids group1}

可以添加至授权组的资源

只能将下列类型的资源添加至授权组：

Cell
节点
服务器集群
服务器
应用程序
节点组

如果资源不是前面列示的任何类型，那么将使用它的父资源。

一个资源只能属于一个授权组。然而，资源之间存在包含关系。如果一个父资源所属的授权组与它的子资源所属的授权组不同，那么该子资源将隐式属于多个授权组。不能将同一资源添加至多个授权组。

下图显示了资源之间的包含关系：

包含关系图

对资源执行操作所需要的特权取决于以下两个因素：

管理资源的授权组。如果用户有权访问授权组，那么将有权访问该授权组中的所有资源。
资源的包含关系。如果用户有权访问父资源，那么将有权访问所有子资源。

密钥库管理要求用户具有单元级别管理特权，因为它们是在单元级别被创建和管理的。对特定资源的细颗粒度安全性访问权不允许管理相关联的密钥库。

表 1. 访问各种管理资源所需的特权。下表中显示了访问各种管理资源所需要的特权：
资源	操作	需要的角色
服务器	启动、停止和运行时操作	服务器操作员，节点操作员，单元操作员
服务器	新建和删除	节点配置员，单元配置员
服务器	编辑配置	服务器配置员，节点配置员，单元配置员
服务器	查看配置和运行时状态	服务器监视员，节点监视员，单元监视员
节点	重新启动、停止和同步	节点操作员，单元操作员
节点	添加和删除	单元配置员
节点	编辑配置	节点配置员，单元配置员
节点	查看配置和运行时状态	节点监视员，单元监视员
集群	启动、停止和运行时操作	集群操作员，单元操作员
集群	新建和删除	单元配置员
集群	编辑配置	集群配置员，单元配置员
集群	查看配置和运行时状态	集群监视员，单元监视员
集群成员	启动、停止和运行时操作	服务器操作员，集群操作员，节点操作员，单元操作员
集群成员	新建和删除	节点配置员，单元配置员
集群成员	编辑配置	服务器配置员，集群配置员，节点配置员，单元配置员
集群成员	查看配置和运行时状态	服务器监视员，集群监视员，节点监视员，单元监视员
应用程序	所有操作	请参阅管理角色中的 "部署者角色" 部分。
节点和集群	添加和删除	单元配置员

服务器操作员角色就是服务器实例所属的授权组的操作员角色。同样，节点操作员角色就是节点实例所属的授权组的操作员角色。

要在管理控制台中使用细颗粒度管理安全性，至少应在单元级别给用户授予监视员角色。但是，要使用 wsadmin 来登录，应为用户授予对任何授权组的监视员角色。

示例：使用细颗粒度安全性。

以下方案描述如何使用细颗粒度管理安全性，尤其是如何使用新的部署角色。

部署角色方案 1。

在以下方案中，在服务器 S1 上配置了四个应用程序，如下表中所示。必须隔离每个应用程序，以便一个应用程序的管理员无法修改另一个应用程序。假定只有用户 1 可以管理应用程序 A1，用户 2 可以管理应用程序 A2 和 A3，并且只有用户 3 可以管理应用程序 A4。

注: 建议不要将应用程序放在一个组中，而将其目标服务器放在另一个组中。然而，并非始终能够做到这一点。通常一个服务器中有多个应用程序。有时仍然需要隔离在同一服务器上运行的应用程序的管理。

应用服务提供商 (ASP) 就是一个示例，其中，单个应用程序服务器可以有多个供应商应用程序。在这种情况下，服务器管理员负责安装所有供应商应用程序。一旦安装了应用程序，每个供应商就可以管理他们自己的应用程序，而不会妨碍其他供应商的应用程序。

表 2。部署角色方案 1 应用程序。
此表列示部署角色方案 1 应用程序。
应用程序	服务器	节点
A1	S1	N1
A2	S1	N1
A3	S1	N1
A4	S1	N1

可以按下图中所示配置授权组：

在该图中，应用程序 A1 在授权组 G1 中，应用程序 A2 和 A3 在授权组 G2 中，而应用程序 A4 在授权组 G3 中。

从授权组 G1 分配了一个部署者角色给用户 1，从授权组 G2 分配了一个部署者角色给用户 2，并且从授权组 G3 分配了一个部署者角色给用户 3。

因此，用户 1 可以对应用程序 A1 执行所有操作，用户 2 可以对应用程序 A2 和 A3 执行所有操作，而用户 3 可以对应用程序 A4 执行所有操作。因为所有应用程序共享同一服务器，所以不能将同一服务器放置在所有授权组中。只有单元级管理员才能安装应用程序。在完成应用程序安装之后，每个应用程序的部署者可以修改他们自己的应用程序。要启动和停止服务器，需要单元级管理权限。此类型的方案在 ASP 环境中很有用。

部署角色方案 2。

在以下方案中，一组应用程序需要对一个服务器的相同管理角色。在此示例中，应用程序 A1 和 A2 是相关的应用程序，它们可由一组管理员管理。它们正在同一服务器 (S1) 中运行。应用程序 A3 和 A4 需要不同的管理员组，它们分别在服务器 S2 和 S3 中运行。

表 3。部署角色方案 2 应用程序。
此表列示部署角色方案 2 应用程序。
应用程序	服务器	节点
A1	S1	N1
A2	S1	N1
A3	S2	N2
A4	S3	N3

可以在客户环境中直接应用的方案。

每个开发者必须能够修改其服务器的配置，并且必须能够在该服务器上安装其应用程序。他们还必须能够启动和停止服务器以及服务器上的应用程序。

开发者还必须能够配置服务器，以便他们可以调试所遇到的任何问题。他们必须有能力更新或修改正在开发的应用程序。此开发者的管理授权组至少包括一个服务器和开发者安装在该服务器上的任何应用程序。

在以下示例中，授权组 G1 的开发者有一个新的应用程序 (A11)。他们可以将这个新的应用程序安装在授权组 G1 中的服务器上并以该应用程序作为目标。并且，他们可以将这个新的应用程序放置在他们的授权组 (G1) 中。

ASP 环境方案。

在此方案中，客户为 ASP。他们有自己的客户并为这些客户提供应用程序服务功能。他们想使其客户能够管理和监视客户的应用程序，但无法访问或管理不同客户的应用程序。然而，在此示例中，ASP 有一些内部职员管理员，其工作是维护服务器。

此内部 ASP 职员管理员可能需要将应用程序从一个服务器移至另一个服务器，以确保应用程序仍然可用。内部 ASP 职员管理员应能够停止和启动这些服务器并且能够更改其配置。

相反，ASP 客户管理员应该无法停止或启动服务器。然而，ASP 客户管理员应该能够更新他们的、在这些服务器上运行的应用程序。内部 ASP 管理员的管理授权组可以是整个单元，也可以包括服务器、节点、集群和应用程序的子集。客户管理员的管理授权组仅包括客户已付费以获取此 ASP 的服务的那些应用程序。

更新配置库时，在 Deployment Manager 中运行管理脚本，以便在 Deployment Manager 端运行管理脚本时，细颗粒度管理安全性规则将生效。

下图包含一个方案，在该方案中，两个不同的客户有两个不同类型的应用程序，他们可以管理自己的应用程序。然而，正在运行应用程序的服务器和节点与他们的客户是隔离开的。服务器和节点只能由内部管理员进行维护。另外，客户不能在不同的服务器上以他们的应用程序作为目标。此操作只能由内部管理员或内部部署者执行。

区域组织方案。

在此方案中，客户为一个全球性大公司。公司的节点和服务器进行了组织，以便为不同区域（或不同行业）提供应用程序服务。他们想要来自不同区域的代表能够监视和管理与该区域相关联的节点和服务器。然而，他们希望区域管理能够影响与不同区域相关联的任何节点和服务器。

每个区域代表的管理授权组包括与该区域相关联的节点、服务器、集群和应用程序。

例如，考虑一个提供多项服务的公司，如提供诸如信用卡帐户、佣金帐户、银行帐户或旅行帐户的金融机构。其中的每项服务都可以是单独的应用程序，而每个应用程序的管理员也必须是不同的。下图显示了配置这种系统的一种方式：

下图显示如何将这种系统中的资源分组以将管理员互相隔离开来。

注意，节点不是任何授权组的一部分。因此，贸易应用程序管理员无法停止任何节点上的服务器，并且他不能停止旅行应用程序。

可以按另一种方式配置相同系统，如下所示：

下图显示如何将这种系统中的资源分组以将管理员互相隔离开来。