Rescoping Spec - 从无范围到有范围¶
限制令牌的范围重定，以防止未经授权的重复使用或权限升级。
问题描述¶
无范围令牌可用于获取范围限定为任何项目或域的令牌。但是，一旦用户拥有了范围限定的令牌，该用户或任何获得该令牌的用户都可以将其交换为另一个项目范围限定的令牌。这不应该允许，因为这意味着任何令牌实际上都是无约束的。为了将范围限定的令牌交换为无范围令牌，用户应该重新进行身份验证以证明对无范围令牌的权利。用户不应该能够将一个范围限定的令牌交换为另一个不同范围限定的令牌。
提议的变更¶
约束令牌创建过程，使得：* 用户必须进行身份验证才能获取无范围令牌。 * 只有无范围令牌才能交换为范围限定为域或项目的令牌。 * 范围限定为域或项目的令牌不能交换为另一个令牌。
备选方案¶
无
安全影响¶
此更改是否涉及敏感数据，例如令牌、密钥或用户数据？
是：令牌换令牌应该受到限制。
此更改是否以可能影响安全性的方式更改了 API，例如访问敏感信息的新方式或登录的新方式？
否
此更改是否涉及密码学或哈希？
否
此更改是否需要使用 sudo 或任何特权？
否
此更改是否涉及使用或解析用户提供的数据？这可能是直接在 API 级别，或间接例如更改缓存层。
否
这个更改是否会引发资源耗尽攻击？
否
通知影响¶
无
其他最终用户影响¶
在绝大多数情况下，这应该对最终用户隐藏。唯一的例外是直接向 Keystone 发送 CURL 请求的人员。Keystone 客户端将在其他地方使这变得无缝。
性能影响¶
现在，许多请求单个、范围限定的令牌将需要多个令牌。第一个将是无范围的，第二个将是范围限定的。Horizon 将是主要使用者，它会看到这一点。但是，在 LDAP 部署中，Horizon 已经以这种方式工作。
其他部署者影响¶
讨论将影响您部署和配置 OpenStack 的事情，这些事情尚未提及，例如
正在添加哪些配置选项？它们是否应该比建议的更通用（例如，其他 hypervisor 驱动程序可能想要实现的标志）？默认值是否适用于实际部署？
一个配置标志，用于启用和禁用此功能
此更改是否在合并后立即生效，还是需要显式启用？
需要显式启用
如果此更改是新的二进制文件，将如何部署它？
否
开发人员影响¶
所有需要多个令牌的服务都必须保留一个无范围令牌才能获取其他令牌。这应该由 keystone 客户端管理。
实现¶
负责人¶
主要负责人
ayoung : Adam Young <ayoung@redhat.com>
其他贡献者
工作项¶
服务器端更改，以拒绝重定范围限定令牌的范围。最初禁用。
对 Keystone 客户端的更改，以维护无范围和范围限定的令牌。
对 Django-OpenStack Auth 的更改，仅尝试从无范围令牌进行范围重定。
依赖项¶
specs/kilo/explicit-unscoped.rst
