领域特定角色¶
扩展了隐含角色的概念，允许先前的角色具有领域特异性，从而允许领域管理员创建对用户有意义的角色。这些角色只是管理角色，并扩展到它们的隐含角色以用于令牌目的。
问题描述¶
角色的现有定义是与策略规则的直接链接，即角色名称是策略中直接引用的项目。 在此蓝图中，我们将这种角色称为“策略角色”。
隐含角色规范创建了一种能力，即可以定义一个先前的角色，该角色在令牌验证时扩展到一组隐含角色。 先前的角色和所有隐含角色最终都将出现在令牌中——也就是说，它们都是策略角色。
引用策略角色的策略文件在任何云环境中都应该受到严格控制。 这些文件中的一个错误可能会造成非常严重的损害。 因此，它们不太可能经常更改。 然而，可能分配给用户的、一组人类可理解的角色建模，可能会经常更改。 例如，在公共云（或通常的多租户云）中，云提供商很可能会发布他们的“角色模型”，列出客户管理员应分配给用户哪些角色才能发出给定的 API。 为了服务于尽可能多的不同客户，这种角色模型很可能比今天更加精细（因为，当然，角色模型对所有客户都是通用的）。
然而，对于特定的客户来说，云提供商选择的任何一组精细角色可能对他们来说没有意义，或者不能代表适合他们特定使用模型的角色的相关分组。 理想情况下，领域管理员希望创建对该领域的特定用户有意义的角色，并以某种方式将这些角色映射到云提供商定义的角色模型。 这些领域特定角色将仅对他们的领域私有，并且仅存在于该领域的命名空间中，因为它们对其他领域的用户可能毫无意义。 此外，这些领域特定角色不应出现在任何令牌中——只有它们映射到的角色（这些是云提供商的角色模型的一部分的策略角色）才应出现在令牌中。
隐含角色能力提供了上述映射，领域特定角色作为先前的角色。 然而，正如目前描述的那样，它要求先前的角色在全局范围内（即不限于领域私有），并且先前的角色也插入到令牌中，因此上述情况不可能实现。
提议的变更¶
我们建议基于隐含角色能力，允许创建领域特定的先前角色。 领域特定的先前角色（只是具有新的 domain_id 属性的角色实体）可用于定义隐含角色（即通过隐含一组策略角色），唯一的区别在于（与常规先前角色相比），在为令牌计算有效角色时，领域特定的先前角色本身将不包含在内。
领域特定角色可以在任何可以使用全局角色今天的地方（就分配 API 而言）使用。 鉴于在令牌生成时，领域特定角色将被扩展到它们的策略角色，因此对 Keystone 以外的服务不会产生影响（并且策略文件不会更改）。 对于 fernet 令牌（无论如何都不包含角色），它们将在令牌验证时扩展。 此外，领域特定角色可以与联合身份验证一起使用，允许来自 IdP 的任何经过身份验证的用户，通过现有的联合映射到 Keystone 组，获得领域特定的角色分配。
角色的 domain_id 属性是不可变的，你无法在全局和领域特定之间切换角色。
备选方案¶
提供领域特定的策略文件的能力。 这将是一项非常复杂的任务。
数据模型影响¶
对于 SQL，角色表将被扩展以支持领域特定角色。
REST API 影响¶
修改角色 API 以允许创建领域特定角色。
安全影响¶
任何对角色或策略模型的更改都有可能影响安全性。 然而，该提案并没有显著增加攻击向量，因为它本质上只是为手动将一组现有的全局策略角色添加到用户提供了一种更方便的替代方案。
通知影响¶
任何现有的关于角色的通知都将扩展到包括领域特定角色。
其他最终用户影响¶
无
性能影响¶
主要影响将发生在令牌生成和验证时，但这与隐含角色总体上没有区别。
其他部署者影响¶
无
开发人员影响¶
无
实现¶
负责人¶
- 主要负责人
henry-nash
工作项¶
添加管理器/驱动程序对领域特定角色的支持
添加领域特定角色的控制器
添加 keystoneclient 库对领域特定角色的支持
添加 openstack cli 对领域特定角色的支持
依赖项¶
测试¶
无
文档影响¶
更改用户文档以描述新的 API。
参考资料¶
无
