Token Provider Cleanup

token-provider-cleanup

对于希望开发自定义提供程序的任何人来说,Token Provider 应该是一个非常简单的类来创建。 这将开放通道,允许在树内和树外都有许多 Token Provider,同时保持 Token 发行 API 合同。

问题描述

截至今天,要创建一个新的 Token Provider(使用新的 ID 格式),需要深入了解 Keystone 如何处理 Token 发行以及所有原始数据应该是什么样子。 Keystone 应该具有一个非常简单且易于理解的 Token Provider 接口。 这使得可以轻松创建新的 Token-ID 格式,这些格式可以/将满足特定的部署需求。

提议的变更

Keystone 的 Token Provider 应该使用 stevedore 加载,并具有极其稳定的 API。 此 API 应该非常稳定(以与我们强制执行 REST API 合同相同的方式强制执行为稳定的合同)。

新接口应为

  • 发行 Token:一种方法,它接受一个清晰的数据模型(类似于 Juno 中引入的当前 Token 数据模型),并允许以可用于生成 Token ID 的方式提取数据。 最极端的情况是 PKI Token,其中所有数据都编码到 ID 本身中。

    发行 Token 方法还将做出诸如将 Token 数据持久化到某种稳定存储和/或预先填充缓存之类的决策。

    需要将 Token-ID 类型编码到 Token ID 中(对于新的 Token 类型),从而允许 Keystone 和中间件加载正确的提供程序来处理 Token 验证。 从长远来看,这将使我们能够支持多种 ID 类型(无缝转换)。

  • 验证 Token:一种方法,它执行验证,并利用 Keystone 的管理器/等来重新生成 Token 数据,或者直接提取数据(在类似于 PKI Token 模型的情况下)。

    验证 Token 将负责在需要时通过 Token 数据格式化程序运行数据。

  • 中间件插件:一个类,可以被 Keystone 中间件用来验证 Token。 默认行为将是利用 UUID 模型,其中中间件执行 HTTP 请求到 Keystone 以验证 Token 并接收 Token 数据/主体。 大多数提供程序可能不会重新实现此功能。 一个将重新实现此功能的示例提供程序将是 PKI Token 提供程序。

    中间件插件将使用与 验证 Token 相同的方法,以避免从持久存储中检索 Token 数据超过一次。

V2 和 V3 Token 辅助类将被重构,以接收 Token 模型并发出记录的 Token 数据格式。 Token 数据格式将记录给开发人员,并为每个版本提供格式化程序类(当前为 V2 和 V3)。

对此 API 的任何更改都需要 100% 兼容(没有引发异常的方式),或者需要 Adapter 类来处理较旧的提供程序接口。

备选方案

无。 这是一种设计变更,另一种选择是保持我们今天所拥有的相同设计。

安全影响

此更改会影响 Token,并且可能对安全性产生影响,但是,目标是保持相同的功能,但重构 Keystone 管理 Token 发行和 Token 验证的方式。

需要评估新的 Token Provider 的安全性。

通知影响

不会产生通知影响。 通知将在提供程序 发行 Token 方法之外处理,确保新的提供程序不需要了解通知/cadf 逻辑。

其他最终用户影响

部署者将能够开发自己的 Token-ID 格式和验证。 这意味着 Token ID 的外观可能会发生变化。 这些更改应该对最终用户是透明的。

性能影响

此更改不应直接影响性能。 但是,这将允许部署者为他们的部署选择最佳的 Token Provider。

其他部署者影响

部署者将能够为他们的部署选择最佳的 Token Provider。 未来的开发将允许使用多个提供程序(验证),以便从一个提供程序切换到另一个提供程序对于最终用户来说应该是无缝的。

开发人员影响

开发人员将拥有一个非常严格的合同 API 来开发提供程序。 这应该会显著改善开发人员的体验。

实现

负责人

Morgan Fainberg <mdrnstm>

工作项

  • 开发增强型 ABCMeta 类型类,以强制执行 Token Provider 上的合同。 这将包括所需方法的签名。

  • 重构 Token 格式化程序类,这些类可以将 Token 数据转换为 Token 模型,反之亦然,用于 V2 Token 和 V3 Token 格式。 这些格式化程序将位于 Keystone 中,并作为任何 Token Provider 的公共接口提供。

  • 整合 Token 发行管道,使其不特定于版本。

  • 开发新的 Token Provider 框架。 这包括从 stevedore 加载。

  • 实现当前支持的 Token 格式(UUID、PKI、PKIZ)的 Token Provider。

依赖项

没有额外的依赖项。

文档影响

  • 需要开发 Token Provider 接口的文档。

  • 需要开发 Token 格式文档。 Token 数据格式将被标记为内部“Keystone”数据结构。

参考资料

没有外部引用。