多领域 Keystone

简介

目前，为了使用给定的 OpenStack 服务——在使用 Keystone 的情况下——，必须在请求中提供由 Keystone 颁发的 Token。这未能实现联合的目标，即运行 OpenStack 实例的客户可以使用其现有的认证 Token 向也运行 OpenStack 的签约服务提供商发出请求。 在此提案中，我提出了一种实现这种联合的机制，以及一种可以帮助简化未来讨论的术语。

“领域”(Realm)

在 OpenStack 的上下文中，“领域”由一组所有依赖于单个 Keystone 数据集进行认证的服务组成。 请注意，这不一定是单个 Keystone 服务：可以使用多个 Keystone 服务； 定义性特征是它们都使用相同的数据集，无论该数据集如何分布。 例如，考虑一家大型托管提供商：他们可能在多个区域分布着许多计算实例，但所有这些实例都将使用通用的、可能冗余的 Keystone 服务。 另一个例子可能是托管提供商的大客户：他们可能有一个或多个区域，但也希望与托管提供商签订合同以提供更多容量或冗余； 同样，他们的所有区域都将使用通用的、可能冗余的 Keystone 服务。

跨领域通信

在上面的消息序列图中，我们看到一个跨领域交互的示例。 在交互的第一个部分，我们看到一个典型的认证查询：用户发出请求，使用来自用户领域的 Token 进行认证，并且此请求被拒绝（因为 Token 来自另一个领域）。 在交互的第二个部分，我们看到用户从服务提供商的领域获得跨领域认证 Token，并且交互的第三部分说明了一个成功的认证请求。 提出的新交互是此跨领域认证步骤，它允许用户使用来自客户领域的 Token 获取服务提供商领域的认证 Token。

跨领域认证

用户生成对服务提供商的 Keystone 服务的请求。 这看起来像一个正常的用户名/密码登录请求，除了会包含对客户的 Keystone 服务的引用以及用户的当前认证 Token； 为了简洁起见，我们将此 Token 称为 `R2_tok`。（假设最初，此入口点将通过扩展定义。）服务提供商的 Keystone 服务将检查此引用并确定客户的 Keystone 服务是否已注册，如果未注册，则请求将被拒绝。（注册要求是建立两个区域之间有限信任关系的第一部分，正如我们稍后在此交互中看到的。）

验证 Token

假设已执行此类注册步骤，服务提供商 Keystone 服务将联系客户的 Keystone 服务以验证 `R2_tok` 的真实性。 虽然这是一个现有操作，但可能需要一个新的端点或验证消息的新参数，以便告知客户的 Keystone 服务这是一个跨领域认证交互的步骤。 这也将允许客户的 Keystone 服务执行授权检查： 假设客户可能希望限制其哪些用户有权访问服务提供商处的客户资产。

已验证的 Token 与用户名映射

在跨领域认证交互中，客户的 Keystone 服务不仅需要验证 `R2_tok` 有效且标识了授权用户，而且还必须将该用户映射到服务提供商的 Keystone 服务所知的用户名。 此外，它必须告知服务提供商的 Keystone 服务与用户对应的租户、组、角色和其他认证数据。 还需要指出的是，客户可能与多个服务提供商建立关系。

服务提供商的 Keystone 服务在收到此消息后，必须对客户的 Keystone 服务提供的数据执行授权检查： 主要确保用户和租户适用于该客户，并且组和角色是合理的。 如果没有此验证步骤，恶意客户可能会获得对服务提供商领域的管理访问权限。 这就是上面第一步中提到的注册信息的作用所在。

认证 Token 与服务目录

一旦交互完成，服务提供商的 Keystone 服务将生成一个新的认证 Token `R1_tok`，并将其返回给用户，以及服务目录。 此消息与 Keystone 服务在用户使用正常的用户名/密码登录时生成的正常消息相同。

Keystone 的必要更改

Keystone 支持跨领域认证所需的主要更改是添加领域概念，以及用于联系远程领域和映射以及授权 Token 验证和认证数据映射的关联数据（将一个领域的用户映射到另一个领域，以及租户、角色、组等的映射）。 从 API 的角度来看，需要一个额外的端点，或者更有可能的是，一个新的登录消息扩展，以及执行跨领域 Token 验证步骤和传输认证数据映射的一种方式。 很有可能，这可以轻松地作为现有 Keystone 服务的扩展来实现。

---