服务令牌复合授权¶
服务令牌背后的概念是提供一种机制，使服务能够以不同的方式处理请求，具体取决于请求是直接从用户接收还是通过另一个 OpenStack 服务接收。
简单的示例请求流程
+----------------+
| User |
+-------+--------+
| Access Image Data Request
| X-AUTH-TOKEN: <end user token>
| X-SERVICE-TOKEN: None
|
+-------v---------+
| Glance |
+-------+---------+
| Access Image Data Request
| X-AUTH-TOKEN: <original end user token>
| X-SERVICE-TOKEN: <glance service user token>
|
+-------v---------+
| Swift |
+-----------------+
问题描述¶
在某些情况下，如果请求不是通过中间服务进行的，而是直接向服务发出的，则以不同的方式处理请求是可取的。
在上面的示例流程中，只能通过 Glance 服务访问镜像数据。如果用户通过 Swift API 直接访问数据，则策略将强制执行 HTTP 403 Forbidden。 这是为了确保用户无法在 Glance Service 知情的情况下更新（维护数据完整性）镜像。
最终用户将向 Glance 发出请求，并提供标准的 Auth Token。 在 Glance 中运行的 auth_token 中间件将授权最终用户发出镜像数据的 API 请求。
Glance 然后将请求发送到 Swift，并提供 End User 的令牌和 Glance Service User 的令牌。 在 Swift 中运行的中间件将解码 End User 的令牌和 Glance Service User 的令牌，并将来自两个令牌的信息呈现给 Swift 服务。 然后，Swift 将做出策略决策，现在能够强制执行请求来自 Glance 而不是直接通过 Swift API。
提议的变更¶
Keystone auth_token 中间件将被修改为接受第二个令牌头：X-SERVICE-TOKEN。 如果提供了 X-SERVICE-TOKEN 头，它将解码服务令牌中的数据，并以与从 X-AUTH-TOKEN 头中解码的数据相同的方式将其呈现给基础服务。 从 X-SERVICE-TOKEN 解码的新数据将使用单独且不同的命名，表明它源自 X-SERVICE-TOKEN（例如，如果从 X-AUTH-TOKEN 头中提取了 HTTP_X_ROLES，则服务等效项将是 HTTP_X_SERVICE_ROLES）。
这将允许在服务内运行的策略引擎基于两个令牌提供的数据做出策略决策，或者根据是否存在（或缺少）任一令牌来做出不同的响应。
备选方案¶
扩展 Trust 系统以支持更具体的角色委托。
扩展 Trust 系统和委托能力将为最终用户提供一个更困难的用户体验。 它需要显式地将角色委托给服务用户，然后发出请求。 服务需要了解显式 Trust 并知道将令牌限定为该 Trust。
这并不能解决保护数据免受绕过服务 CRUD 操作的愿望（例如，
Glance将镜像存储在Swift中）。继续仅使用用户的权限和 bearer 令牌。
这并不能解决保护数据免受绕过服务 CRUD 操作的愿望（例如，
Glance将镜像存储在Swift中）。从 Keystone 请求的复合令牌，将两个原始令牌合并到一个新令牌中。
此规范的原始概念包括从 Keystone 请求一个新令牌。 此新令牌将包含两个原始令牌的元素。 此机制将提供与服务令牌相同的优势，并允许服务了解请求所经过的整个路径（例如，User -> Nova -> Glance -> Swift）。
最大的缺点是需要在每个步骤中向 Keystone 请求一个新令牌（并强制 Keystone 解决是否允许颁发新令牌）。 额外的往返 Keystone 会引入显著的开销，而收益却很小：要求每个步骤直接与 Keystone 通信，消除了在
auth_token中间件中本地解码/验证 PKI 令牌的好处。 基于整个请求路径的复杂策略决策将是一个极端的边缘情况，并且不能证明往返 Keystone 服务的额外开销。OAUTH
Keystone 中 OAuth 的当前实现与扩展 Trust 系统类似。 它还具有全局配置选项上的固定续订要求。 这将需要持续重新验证访问（和/或请求）令牌（最终用户干预）。 修改 OAuth 系统以符合新的用例将改变用户当前交互（和期望 OAuth）的方式，可能会破坏 OAuth API 中定义的合同，并要求最终用户更新所有当前使用 OAuth 系统的工具/脚本/等。
数据模型影响¶
无
REST API 影响¶
无
安全影响¶
描述对系统造成的任何潜在安全影响。需要考虑的一些项目包括
此更改是否涉及敏感数据，例如令牌、密钥或用户数据？
这为支持第二个令牌以用于策略执行目的向运行在
auth_token中间件后面的服务传输数据引入了支持。此更改是否以可能影响安全性的方式更改了 API，例如访问敏感信息的新方式或登录的新方式？
策略执行现在可以访问服务令牌中的数据。 这不会在没有对
auth_token中间件后面的服务的策略进行显式更改的情况下更改对敏感信息的任何访问。此更改是否涉及密码学或哈希？
否
此更改是否需要使用 sudo 或任何特权？
否
此更改是否涉及使用或解析用户提供的数据？这可能是直接在 API 级别，或间接例如更改缓存层。
否
此更改是否会启用资源耗尽攻击，例如允许单个 API 交互消耗大量的服务器资源？这方面的一些例子包括为每个连接启动子进程，或 XML 中的实体扩展攻击。
与普通的 PKI 令牌一样。
通知影响¶
不会发生额外的通知事件。 CADF 身份验证事件将在服务用户对其服务令牌进行身份验证时发出。
其他最终用户影响¶
除了 API 之外，用户还有其他方式与此功能交互吗？
keystoneclient中的会话对象需要支持能够发送X-SERVICE-TOKEN头。 这只会影响服务使用各种 Python 客户端库来消耗keystoneclient会话进行身份验证的情况。
性能影响¶
解码来自
X-SERVICE-TOKEN头的信息需要额外的调用 CMS（子进程）或向Keystone发出请求，以防 UUID 令牌。只要令牌即将过期，服务应尝试重用其服务令牌。 这将限制往返 Keystone 以请求提供在
X-SERVICE-TOKEN头中提供的新的令牌。 每个服务将负责根据需要刷新其服务令牌。包含的令牌导致请求开销翻倍。
其他部署者影响¶
讨论将影响您部署和配置 OpenStack 的事情，这些事情尚未提及，例如
正在添加哪些配置选项？它们是否应该比建议的更通用（例如，其他 hypervisor 驱动程序可能想要实现的标志）？默认值是否适用于实际部署？
任何更新为利用发送
X-SERVICE-TOKEN头的服务都需要添加服务用户凭据的选项。此更改是否在合并后立即生效，还是需要显式启用？
任何利用
X-SERVICE-TOKEN头的服务都需要构建明确的策略来基于额外头中的数据进行强制执行。 任何希望发送X-SERVICE-TOKEN头的服务都需要配置服务用户凭据。请说明那些进行持续部署的人员，或那些从以前的版本升级的人员需要注意的事情。此外，请描述弃用配置值或功能的计划。例如，如果我们将实例存储的目录名称更改了，我们如何处理更改着陆之前创建的实例目录？我们是否移动它们？我们是否在代码中有一个特殊案例？我们是否假设操作员将重新创建云中的所有实例？
利用复合授权实现的服务中的更改应该是（大部分）透明的。 这将是部署策略以启用（最多）。
开发人员影响¶
讨论将影响在 OpenStack 上工作的其他开发人员的事情，例如
开发人员需要利用来自
keystoneclient的新的Session对象进行身份验证，以向外部服务确保在向外部 OpenStack 服务发出请求时正确填充X-SERVICE-TOKEN。
实现¶
负责人¶
- 主要负责人
摩根·费因伯格 (mdrnstm)
- 其他贡献者
Stuart McLaren
工作项¶
auth_token中间件支持解码和呈现来自X-SERVICE-TOKEN的数据KeystoneClient 会话对象支持
X-SERVICE-TOKEN跨项目协作以利用和/或记录使用来自
X-SERVICE-TOKEN的数据进行强制执行的策略建议。
依赖项¶
无
测试¶
需要开发 auth_token 中间件的单元测试，以验证来自 X-AUTH-TOKEN 和 X-SERVICE-TOKEN 的数据是否正在呈现给基础服务。
当服务能够发出新的头并强制执行通过 auth_token 中间件收到的额外信息上的策略时，需要 Tempest 测试来验证新的策略模型。 使用新的 X-SERVICE-TOKEN 头将使用策略 DSL 中的逻辑 and 和逻辑 or 机制来强制执行服务令牌数据和用户令牌数据的组合。
文档影响¶
需要编写部署文档更改和最佳实践（服务用户创建、角色分配等）。
需要创建示例策略文件，以显示如何在做出策略执行决策时使用从
X-SERVICE-TOKEN提供的新数据。
