使用 CA AppLogic® › 网格管理指南 › Role-Based Access Control › 示例方案

示例方案

CA AppLogic® 不提供预定义的组和用户的广泛方案。 这允许网格管理员设置用户、组和对象的访问权限，以适合每个特定情况。 通常，网格管理员执行以下这些步骤：

• 创建本地用户。
• 创建一整套本地组。 这些组可用于隔离用户，按工作类型（例如，网格管理、应用开发、QA 等）、业务结构（例如，按部门或业务单位，以便用户的不同组可以为开展工作共享网格）或其他实际的分类。 使用全局组也可达到同样的效果，针对两个或更多网格使用相同的设置时，将十分有用。
• 在适当的情况下将用户添加到组，或将组添加到组。
• 修改对象 ACL 为组分配特定的访问级别权限。

下列方案提供该过程可以有效控制用户访问方式的实际示例。

Ace Starships Incorporated (ASI) 建造宇宙飞船。 每个宇宙飞船包括许多其他的生命支持和推进的软件系统。 将这二个软件系统部署到实际宇宙飞船的生产网格之前，会在一个大型共享的 CA AppLogic® 网格上进行开发。 该网格的开发过程包括以下各方：

• 生命支持开发团队
• 推进开发团队
• Outsiders－中间设备组件开发中的专家（普通组件）
• Auditors－需要非破坏性访问开发的 ASI 人员
• QA－质量保证人员，测试开发团队和 Outsiders 的产品

此外，我们还有：

• 全局用户 john_adams，网格管理员－负责网格管理的人
• 全局用户 jane_osprey，网格操作员－管理员休息时负责管理网格的人

而且：

• ASI 使用基于全公司 LDAP 的目录服务进行集中式的用户和组管理。 每个人（除 Outsiders）在该系统上都拥有帐户。
• 推进团队使用生命支持团队创建的几个应用，但不会修改这些应用的体系结构。
• 两个团队都使用 Outsiders 开发的组件，但不会修改这些组件。
• 全局目录（包含不同开发工作所特有的组件）：life_support、propulsion 和 outsiders。

该方案中作出的第一个决定之一是：是否使用全公司目录来管理组成员身份，还是是否使用本地组管理此成员身份。 在该示例中，我们采取第一个方法：

• 使用 ASI 全公司目录，创建组 life_support、propulsion、QA 和 auditors，并包括在相应全局用户的这些组中。 在 CA AppLogic® 之外执行该操作。

继续我们的示例，初始 CA AppLogic® 用户（本地组 admin 的成员），执行下列用户和组设置：

• 为每个 Outsiders 创建本地用户帐户。
• 创建以下本地组：
  • outsiders
  • grid_operators
  • app_developers
• 设置组成员身份：
  • 将创建的本地用户添加到本地组 outsiders 中。
  • 将全局组 life_support、propulsion 和 QA 添加到 app_developers 组中。
  • 将本地组 outsiders 添加到 app_developers 组中。
  • 将全局用户 john_adams 添加到 admin 组中
  • 将全局用户 jane_osprey 添加到 grid_operators 组中
• 修改对象 ACL 以设置对象访问权限：
  • 将网格 ACL 修改为：
    • 向本地组 grid_operators 提供 grid_operator 访问级别权限。
    • 向本地组 app_developers 提供 app_developers 访问级别权限。
    • 向全局组 auditors 提供 monitor 访问级别权限。
  • 将全局目录 ACL 修改为：
    • 向全局组 life_support 提供 life_support 目录上的、向全局组 propulsion 提供 propulsion 目录上的以及向本地组 outsiders 提供 outsiders 目录上的 full 访问级别权限。
    • 向本地组 app_developers 提供 outsiders 目录上的、向全局组 propulsion 提供 life_support 目录上的 configure 访问级别权限。

下表在我们的方案中显示组成员身份：

下表显示授予我们方案中相应对象的主体的访问级别权限：

用户和组初始设置现在完成。 在此，属于全局组 life_support、propulsion、QA 和 auditors 的全局用户可以登录到网格，且自动为每个用户提供执行工作的必要访问级别权限。

也设置了对全局目录的访问，因此根据需要可以访问组件，但仅有在目录上有 full 访问级别权限的组的成员可以在该目录上执行破坏性操作。

在用户创建新应用时，该用户成为应用所有者，并在该应用上被授予 full 访问级别权限。 在某个时候，用户可能要修改应用 ACL，为他的开发团队或其他团队成员提供访问应用的权限。 例如：

• 生命支持团队的成员可以在应用上授予本地组 life_support full 访问级别权限，以便其他团队成员可以任意修改它。
• 生命支持团队的成员可以授予本地组 propulsion 对应用的 configure 访问级别权限，以便该组成员可以配置或使用应用，但无法修改其体系结构。
• 生命支持团队的成员可授予全局组 QA 用于测试应用任何访问级别权限（例如，read 权限，复制独立测试的应用，configure 权限，配置或使用应用而不修改其体系结构等）。