检索认证范围数据¶
我们需要路由来检索与当前认证范围相关的信息。
问题描述¶
确定与当前授权范围相关的数据需要从令牌中提取信息，然后基于这些信息构建 URL。这对于信息基于多种因素的调用来说是一个问题。对于客户端来说也是一个问题，因为我们正在积极地封装认证信息，以便您不必知道当前认证的参数。
最近已经有变更来基于当前认证令牌暴露服务目录。然而，这并不是需要基于每个令牌确定唯一的事情。例如，联合令牌需要一个单独的 URL 来确定项目，因为无法确定一个可以放入标准 URL 中的 user_id。
提议的变更¶
我建议重新利用 /auth URL 的剩余部分，以提供基于当前认证范围的资源。这有一些直接的 URL 端点。
创建
GET /v3/auth/projects。这将列出可以使用当前令牌作为认证请求的新作用域令牌的项目。此路由可以用作联合和基于常规用户的项目查找的替代方案。它将允许通过用户关联以外的方式将项目与当前认证关联。弃用GET /v3/OS-FEDERATION/projects，而支持此方法。创建
GET /v3/auth/domains。列出可以使用当前令牌作为认证请求的新作用域令牌的域。与项目一样，这结合了联合和常规域查找的情况。弃用GET /v3/OS-FEDERATION/domains，而支持此方法。
我认为这也有助于简化安全模型，因为这意味着所有对 /auth 的请求都完全基于当前的认证范围，而不是处理将筛选参数与当前范围匹配的问题。
它也为基于 user_id 以外的更多内容来匹配可用项目和域打开了未来的选项。
目前，我没有提议添加 POST 或修改 URL 的路由，尽管以后可能需要这些。
备选方案¶
本质上，我们可以继续沿用当前路径。添加一个新的 GET v3/catalog 路由，该路由很有用但与 API 的其余部分不一致，并且需要客户端记住您是否需要通过联合端点或常规项目列表来列出项目，具体取决于令牌类型。
安全影响¶
无。所有信息目前都可通过现有 API 以不太方便的方式获得。
通知影响¶
无。
其他最终用户影响¶
它简化了客户端的视角，因为您不需要知道您拥有的令牌类型来列出项目/域。总的来说，它简化了接收有关当前令牌的信息，包括现有信息以及我们未来选择暴露的任何信息。
性能影响¶
无。
其他部署者影响¶
这有望使 /v3/OS-FEDERATION/projects 和 /v3/OS-FEDERATION/domains 端点变得冗余。我们可能希望将来自那里的请求重定向到新的端点。
开发人员影响¶
无。
实现¶
负责人¶
- 主要负责人
jamielennox
其他贡献者
工作项¶
为项目和域创建新路由，合并联合和列表 API。
弃用相应的 OS-FEDERATION 路由。
通过 keystoneclient 暴露此信息。
依赖项¶
文档影响¶
新的 API。可能对关于令牌作用域的标准工作流的文档进行一些更改。
参考资料¶
无。
