是不是类似group么?
基于角色和基于组的访问控制还是有差别的。
他们二者的区别在于对权限本身的视角不一样,组是拥有相同权限的用户的集合,角色是拥有特定权限的一类用户的代称。
也就是说,组是用户的集合,然而并不是权限的集合角色是权限的集合,同时也具备用户集的概念
当使用组的访问控制系统,只允许特定人员赋予组所有的权限的时候,那么就和角色的概念很相近了。组可以作为实现RBAC的一种策略。
以上内容都可以在RBAC的最初论文中找到完整的解读,手机码字就不贴文献引用了先,这论文应该是九十年代的了,很经典,也很好找,翻译版也有,希望深究的话推荐一读!
openstack的角色是对项目而言,不是对用户,当把一个用户添加到某个项目下的时候必须赋予这个用户在这个项目下的操作权限:角色。角色实现的后台机制就是openstack的policy规则,这套规则的作用粒度是对api操作做规则坚持,目前只有两类角色,admin和普通角色(heat等等会创建一些角色来做访问控制)。
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
暂无简介
文章 0 评论 0
接受
发布评论
评论(2)
基于角色和基于组的访问控制还是有差别的。
他们二者的区别在于对权限本身的视角不一样,组是拥有相同权限的用户的集合,角色是拥有特定权限的一类用户的代称。
也就是说,组是用户的集合,然而并不是权限的集合
角色是权限的集合,同时也具备用户集的概念
当使用组的访问控制系统,只允许特定人员赋予组所有的权限的时候,那么就和角色的概念很相近了。组可以作为实现RBAC的一种策略。
以上内容都可以在RBAC的最初论文中找到完整的解读,手机码字就不贴文献引用了先,这论文应该是九十年代的了,很经典,也很好找,翻译版也有,希望深究的话推荐一读!
openstack的角色是对项目而言,不是对用户,当把一个用户添加到某个项目下的时候必须赋予这个用户在这个项目下的操作权限:角色。角色实现的后台机制就是openstack的policy规则,这套规则的作用粒度是对api操作做规则坚持,目前只有两类角色,admin和普通角色(heat等等会创建一些角色来做访问控制)。