联合区域认证授权

• Launchpad 条目: NovaSpec:nova-zones-federated-authz
• 创建者: SandyWalsh
• 贡献者:
• 相关: ZonesOauth http://etherpad.openstack.org/nova-oauth

总结

在当前的区域实现中，所有对子区域的操作都使用管理员帐户完成。虽然这可行，但在某些重要的用例中会引起问题。特别是当用户希望查看他可以管理的所有实例时。使用管理员帐户的方法，会返回子区域中的所有实例，而实际上应该只返回一部分（取决于用户的权限）。

此页面是与 eday、vish、jorge、khaled 等人讨论的结果，并试图总结其他用例中可能出现的问题，以及记录当前正在进行中的解决方案提案。

修订历史

1. 初稿 - 认证授权服务器通信和同步。 MyCo 用户被主动添加到资源组。
2. 意识到 SP 认证授权不需要知道用户，只需要资源组。引入了“代表...”的概念。移除了认证授权同步。

前提条件

这将是这些用例的大部分常见场景。

MyCo 是一家小型软件开发公司。他们有一个 Nova 部署，由两个区域（父区域和子区域）组成。当这两个区域无法提供更多实例时，MyCo 会外包给服务提供商 (SP) 来处理额外的任务。SP 规模很大，拥有许多地理位置分散且嵌套多层的区域。

在我们的用例中，有两个主要用户：Alice 和 Bob。Alice 管理她自己的实例，Bob 也是如此。但是，Alice 和 Bob 也是一个财务任务组的成员，这使他们能够管理该组控制下的任何实例。

每个业务将有一套认证和授权服务。 MyCo 拥有自己的认证/授权服务，SP 也是如此。这些认证服务需要是高可用的。

每当用户被添加到/从安全组中，或权限更改时，这些操作都在 MyCo 侧完成。只有资源组 ID 会传递给 SP。

在身份验证后，MyCo 授权将向 SP 提供一组关于用户的数据。该数据集包括

• 用户所属的资源组 ID（而不是该组内的资源 ID，这些数据仅存在于 MyCo 授权中）
• 可选地，用户代表...的资源组 ID。
• 一组权限元组（[动作组，...]，[资源组，...]），表示用户可以在哪些资源组上执行哪些操作。

对于同一业务内的子区域（例如，服务提供商中的所有子区域），组 ID 和资源 ID 必须在区域之间是唯一的。

在多租户场景中，例如服务提供商，从一个授权系统传递到另一个授权系统的组标识符需要加上前缀/命名空间以避免冲突。

术语

• MyCo.authZ = 运行在 MyCo 的授权服务
• SP.authZ = 运行在服务提供商处的授权服务
• 主体 = 执行操作的用户。
• 委托人 = 代表另一用户执行操作的用户。
• 主体组 = 用户或委托人的组。
• 动作 = 在资源上执行的动词。例如：启动、停止、暂停、救援、迁移、查看、删除等。
• 动作组 = 动作的集合。
• 资源 = 主体执行动作的对象（我们之前讨论中的“对象”）。
• 资源组 = 资源的组。

设计

在对服务提供商区域进行身份验证 Alice 后，MyCo.authZ 将向 SP.authZ 提供一组权限元组，指示 Alice 可以执行哪些操作以及她可以在哪些资源上执行这些操作（如果适用）。这些元组具有映射 (Action_Groups, Resource_Groups)。请注意，由于用户必须先通过身份验证才能访问系统，因此主体是隐含的。

顺便说一下：曾讨论过将元组设为 (Action_Group, User_Group)，其中 User_Group 是拥有资源的用户的集合。这种方法的缺点是它不够精细。例如，如果 Bob 具有权限 (can_halt, [Alice])，那么他可以停止 Alice 拥有的所有实例。权限太大了。此外，跟踪 User_Group 和 Resource_Group 的区别微乎其微。跟踪 Resource_Group 更符合

我们不希望元组过于精细，以至于列出单个实例 ID……它无法扩展到数千个实例。虽然这会更容易，但我们不希望权限元组为 (Action_Group, [资源 ID])，例如 (can_halt, [ami-AAA, ami-BBB, ami-CCC, ...])。相反，我们需要在 SP.authZ 层定义一个资源组，并在我们的权限元组中简单地引用它。

如何？为了做到这一点，MyCo.authZ 需要使 SP.authZ 保持一组离散的资源组的更新。

MyCo.authZ 将拥有许多资源组，并且这些资源组的大部分内容将包含位于 MyCo 区域中的资源。我们不需要将所有这些信息复制到 SP.authZ……只有引用位于 SP 区域中的资源的组的子集。例如，Bob 在 MyCo.authZ 侧的允许组可能如下所示

(Bob, [can_halt, can_see, can_boot, ...], [myco-Foo-group, myco-Bar-group, myco-Zoo-group, sp-Alice-group, sp-Bob-group sp-Finance-group])

但是，在将其传递给 SP.authZ 时，只需要以下内容

([can_halt, can_see, can_boot, ...], [sp-Alice-group, sp-Bob-group sp-Finance-group])

您可以将此视为 vish 和 termie 提出的 authn/z 分支中“覆盖”功能的正式化。

代表...

我们遇到的一个复杂问题是在 SP 侧创建新资源。我们希望确保将正确的资源组分配给资源。有几种可能性

1. 当用户身份验证时，我们添加一个“On-Behalf-Of=<资源组 ID>”标头，指示应如何分配新资源。这可能很难预先确定。
2. 我们始终在创建新资源时创建一个新的资源组，然后根据需要将此资源组嵌套在其他资源组中以授予权限。

未解决的问题

http://paste.openstack.org/show/1108/

---