隐含角色 - 分配一个角色，获得多个¶
允许角色定义隐含其他角色定义，以便通过一个高级角色分配，用户将继承所有下级角色。
问题描述¶
OpenStack 正在尝试解决规模问题。RBAC 模型需要支持改进的委派，以便扩展。
Keystone 角色映射到一组执行资源操作的权限。目前，定义的角色相对较少，每个角色映射到大量的 API。这是非常粗粒度的访问控制。如果部署者要提供更细粒度的模型，角色的数量将迅速增加。为了减轻管理员的负担，必须能够通过单个角色分配授予用户特定项目所需的全部权限。使用当前的角色分配机制这是不可能的。
随着组织规模的扩大，层级结构也必须相应增加，否则管理者很快就会被下属的大量请求淹没。管理者对下属执行的所有操作负责，即使他们从未直接执行这些操作。执行这些操作的权限来自上级到下级的授权。如果上级无法适当委派，组织就无法正常运作。
与自动化系统交互时，用户应该能够委派其能力的一个子集。如果用户是系统管理员，当所需操作不是特权操作，甚至只影响资源的一个子集时，将完全管理权限委派给用户是不负责任的。即使是普通用户也应该能够提供对其资源子集的访问权限，而无需提供对其所有资源的完全访问权限。为了以这种方式拆分权限，角色需要提供足够的信息来推断更大的更强大的角色隐含着更小更有限的角色。使用当前的角色分配机制也无法做到这一点。
提议的变更¶
用户被分配到项目中的角色以执行操作。为了更好地模拟大型组织的典型层级授权模型，我们将允许定义角色之间的关系，其中一个（更大更强大的角色）可以隐含用户也获得一组更小（更弱）的角色。
通常，这些操作必须由具有不同角色的用户执行。因此，可以将角色视为一个层级结构；更大的角色继承分配给更小角色的权限。为了实现这个层级结构，角色之间的关系必须清楚地表明何时一个先前角色隐含另一个角色。
在持久化存储中，定义一组规则，说明一个先前角色分配隐含额外的角色分配。
例如，如果一条规则说明 admin 隐含 member，那么任何被分配 admin 角色的用户将自动获得 member 角色。
首次实现是 SQL 后端。如果需要，其他后端将随之而来。添加一个额外的 implied_role 表，包含两列
prior_role_id, implied_role_id
这通常被称为层级角色，但此实现避免了严格的层级结构，而倾向于生成有向无环图 (DAG)：相同的角色可能由多个先前角色隐含。在执行时，所需的抽象是角色分配集，而不是树或图。
一个隐含角色的示例集
reader 角色适用于需要能够检查项目中资源的值，但不能对这些资源进行任何更改的人员。
editor 角色适用于需要进行标准更改的人员，例如创建新的虚拟机和分配浮动 IP 地址。所有具有 editor 角色的用户都应该可以访问 reader 角色指定的资源。
每个服务都有自己定义的 admin 角色。此外，这两个以存储为重点的服务还有一个名为 storage_admin 的联合角色，该角色隐含 swift_admin 和 cinder_admin。
如果用户在项目中被分配了 all_admin 并请求该项目的令牌，则令牌将包含所有隐含角色：cinder_admin、neutron_admin、glance_admin、swift_admin、editor 和 reader。
任何形式的 admin 都隐含着 editor。 reader 可以查看任何系统的标准数据，但不能影响任何更改。 editor 角色优于 reader，没有理由在不分配 reader 角色的情况下分配 editor 角色。我们经常希望分配 reader 角色而不分配 editor 角色，用于审计和监控。
角色关系在此 DAG 图中说明。先前角色位于隐含角色之上，箭头显示隐含方向。下表也明确显示了这些关系
all_admin
|
V
+--------------+-------------+---------+----------+
| | | | |
| | | V |
| | | storage_admin |
| | | + |
| | | +-----+------+ |
V V V V V V
neutron_admin glance_admin swift_admin cinder_admin
| | | |
+--------------+-------+-----+--------------------+
|
V
editor
|
V
reader
请注意，它不是严格的层级结构。例如，neutron_admin 和 glance_admin 角色都隐含 editor 角色。
这是一个示例实现
+=================+====================+
| prior_role_id | implied_role_id |
+=================+====================+
| all_admin | neutron_admin |
+-----------------+--------------------+
| all_admin | glance_admin |
+-----------------+--------------------+
| all_admin | swift_admin |
+-----------------+--------------------+
| all_admin | cinder_admin |
+-----------------+--------------------+
| all_admin | storage_admin |
+-----------------+--------------------+
| storage_admin | swift_admin |
+-----------------+--------------------+
| storage_admin | cinder_admin |
+-----------------+--------------------+
| neutron_admin | editor |
+-----------------+--------------------+
| glance_admin | editor |
+-----------------+--------------------+
| swift_admin | editor |
+-----------------+--------------------+
| cinder_admin | editor |
+-----------------+--------------------+
| editor | reader |
+-----------------+--------------------+
显式分配和隐含的角色都将包含在令牌验证响应中。使用上面的示例，如果用户在项目上显式分配了 editor 角色，则针对该用户和项目范围的令牌验证将包含 editor 和 reader 角色在响应中。
配置文件的 [token] 部分中的一个初始配置选项 infer_roles 将控制在颁发令牌时是否扩展角色。
备选方案¶
通过简单地将用户分配给高级角色并继承所有下级角色来消除角色层级结构。然后他继承了所有角色分配的全部权限。角色层级结构的优势在于，用户不需要随身携带所有下级角色，因为系统知道角色层级结构。
角色隐含规则可以与令牌分开获取，缓存在 auth_token 中间件中，然后在策略执行之前从令牌推断角色。如果需要，这将实现。
动态策略机制可以使用隐含角色生成策略文件的一部分。
安全影响¶
此更改是否涉及敏感数据，例如令牌、密钥或用户数据？
是：令牌创建过程现在将向令牌添加更多角色，尤其是在层级结构中较高的角色。创建隐含角色的能力是一种非常敏感的能力，应该受到严格控制。
此更改是否以可能影响安全性的方式更改了 API，例如访问敏感信息的新方式或登录的新方式？
是。角色分配现在可能具有相关的隐式分配。
通知影响¶
每次更改隐含角色规则时，将发送一个通知。
其他最终用户影响¶
一旦此更改到位，策略文件中的角色检查应该简化为检查一组较小的潜在角色。
性能影响¶
令牌验证响应将更大。
如果角色集变得太大，则执行策略可能会稍慢。
其他部署者影响¶
更改立即生效，但默认情况下不会定义任何隐含角色。
如果没有配置选项更改，则不会执行任何角色推断。
开发人员影响¶
无。
实现¶
负责人¶
- 主要负责人
ayoung
- 其他贡献者
无
工作项¶
所有代码更改必须在 Assignments 后端中。
为实体添加父字段
扩展创建和编辑隐含角色 API
添加通知
在列出角色分配时考虑层级结构
依赖项¶
无
文档影响¶
RBAC 的文档需要涵盖角色的层级结构。
参考资料¶
NIST RBAC http://csrc.nist.gov/groups/SNS/rbac/ http://csrc.nist.gov/rbac/sandhu-ferraiolo-kuhn-00.pdf
向基于角色的访问控制添加属性 http://csrc.nist.gov/groups/SNS/rbac/documents/kuhn-coyne-weil-10.pdf
ABAC 和 RBAC http://csrc.nist.gov/groups/SNS/rbac/documents/coyne-weil-13.pdf
