客户端认证插件

旧设计页面

此页面用于帮助设计一个已实现的功能。因此，此页面可能不会更新，并且可能包含过时的信息。上次更新时间为 2013-12-12

在服务器端集成 Keystone 相对简单：引入 auth_token 中间件，如果需要，添加适当的中间件以进行实际集成，结果就是统一的 Keystone 认证。

然而，我们尚未真正研究将 Keystone 集成到我们的客户端工具中。这是一个更复杂的问题，因为每个工具都使用自己的框架，并且这些框架中没有一个真正具有在这种情况下有用的中间件概念。此外，我们必须在 Python API 级别和 CLI 级别处理这个问题。

一种可能的方法是创建一个单一、统一的插件（一个“AuthPlugin”类），该插件将与 Keystone 集成——当然，要使用其他认证系统，只需切换该插件即可。该插件集中了执行认证所需的所有逻辑，并宣传

它执行其工作所需的信息（用户名、租户、密码、认证 URL，等等）
认证执行完毕后它提供的信息（服务的基本 URL、认证令牌等）
它需要对传出的请求执行的转换

当然，第三项是最复杂的，因为插件可能需要注入头部（“X-Auth-Token”），重写 URL，重写请求体，捕获与认证相关的状态码，甚至可能在检索到更新的认证信息后重新提交操作。

认证插件将与客户端提供的一个对象（一个“AuthSvc”对象）一起工作，该对象将告诉插件它需要了解客户端的哪些信息，例如要查找基本 URL 的服务名称，以及提供一个接口来提交对任意 URL 的请求（这样我们可以避免重复发明轮子或引入外部客户端框架）。它还将具有必要接口，以便根据与认证相关的状态码重新提交插件挂钩的操作。

从图形上来看，这种架构如下所示

预期的逻辑流程如下

客户端通过检查 AuthPlugin（可能调用类方法）确定所需的认证信息
客户端实例化其 AuthSvc 类，并将对象传递给 AuthPlugin 构造函数
客户端通过调用插件的 auth() 方法并提供适当的参数，向 AuthPlugin 提供它所需的认证信息
AuthPlugin 使用认证信息执行认证，并返回一个对象，其中包含目标基本 URL 以及它可能需要认证单个请求的一些信息
- AuthPlugin 的查询提交使用 AuthSvc 对象提供的服务，该对象由客户端创建
- AuthPlugin 将使用它从 AuthSvc 获取的信息来确定有关客户端的信息，例如客户端针对的服务（nova、glance、swift 等）
客户端对目标基本 URL 执行其查询，并调用适当的 AuthPlugin 方法来确定要注入的头部、URL 重写甚至主体重写
客户端从远程端接收响应，并再次调用适当的 AuthPlugin 方法来验证响应。
- 客户端必须准备好 AuthPlugin 可能会指示需要使用新信息重新发出请求，例如在令牌过期的情况下

相应的蓝图是：https://blueprints.launchpad.net/glance/+spec/pluggable-auth