将认证与 API 版本分离¶
目前，认证直接绑定到 Keystone 的 API 版本。这意味着我们使用 /v3/auth 和 /v2.0/tokens 作为认证的相应位置。认证是一个与 Keystone 的 CRUD 接口交互不同的关注点。因此，处理认证的位置应该与 API 版本分离。
问题描述¶
随着隔离认证（通过 keystoneauth 库）以及通常清理 Keystone 从最终用户角度的工作方式，将认证移动到 /auth 位置以处理所有认证请求将是一个改进。
这样做还有一个好处，就是将认证响应与特定的 API 版本解耦。如果需要认证变更，返回的数据契约不会像今天这样被锁定，可以创建一个新的认证版本，而无需更改 Keystone 的 CRUD API，因为认证现在已经解耦。
提议的变更¶
此处提出的更改是在根目录下添加 /auth 作为处理认证请求的主要位置。在此新位置下，认证将与今天的工作方式相同，但会进行以下更改
可以在 post 数据体本身中请求认证版本（例如 v2.0、v3 等）。
对
/auth的 GET 请求将显示（用于发现目的）可用的认证版本。/auth/catalog将用于获取给定 token 的目录，并进行适当的过滤。如果未请求版本，默认认证版本将为 v3。新的
keystoneauth库将被更新为始终请求其支持的最高版本。需要认证版本才能知道 token 数据应该是什么样子。这将默认为发行 token 的默认版本。
联合身份验证也将移动到
/auth下，而不是要求使用OS-FEDERATION下的资源。
当前的认证位置将在后端连接到新的认证系统，以确保认证只有一个路径。旧的认证位置将被弃用（但没有移除计划），直到整个 API 被弃用（例如，当 V2.0 被移除时，/v2.0/tokens 位置将被移除，但不会提前移除）。
注意
具体的 API 更改和更深入的设计细节需要在将此功能从积压中移动到接受的规范位置以供发布时进行处理。
备选方案¶
没有直接的替代方案。新的认证机制/返回的数据的更改或认证处理方式的更改，无论哪种情况，都需要一个新的 URL 位置来处理请求。
安全影响¶
此更改会影响认证发生的位置，并可能导致 token 处理方式的更改。这意味着需要评估新的 API 是否存在安全漏洞。一般来说，安全性不应受到影响或隔离到给定的认证版本。
通知影响¶
通知不会受到影响。
其他最终用户影响¶
这将改变认证的工作方式，但是旧系统将继续工作。通过使用
keystoneauth作为库，此更改应该对新库的消费者来说是无缝的。
性能影响¶
没有性能影响。
其他部署者影响¶
部署者特定的影响应该很小。不使用 keystonemiddleware（它将使用 keystoneauth 库，因此应该能够使用新的认证机制而无需额外开销）的外部应用程序和服务需要了解新的认证位置以及如何进行认证。
在大多数情况下，这应该很小，因为旧的认证位置不会被移除。
开发人员影响¶
开发人员需要了解新的认证 API 的工作方式。但是，影响应该很小，因为旧的认证位置将继续工作。建议所有认证都通过新的 API 进行。
实现¶
负责人¶
待定
工作项¶
实现新的
/auth路由（API TBD，待从积压中移除后确定）将旧的认证路由连接到新的机制，以便认证在一个地方处理
更新客户端和中间件以使用新的
keystoneauth库。确保
keystoneauth库能够使用新的认证位置。
依赖项¶
这取决于 keystoneauth 成为一个真正的库并在客户端和中间件中使用。
文档影响¶
需要有关新 API 的文档。
