RBAC的定义
RBAC是基于角色的访问控制（Role-Based Access Control）。角色是资源访问权限的集合，通过为用户指定角色来使得用户具有访问资源的权限。例如，系统有一个角色是会计，它具有查看、修改财务报表的数据，然后指定小王具有会计角色，然后小王就具有了查看、修改财务报表数据的权限了。示意图如下：
RBAC的基本元素
-
用户 users：主体，即需要访问系统资源的个体或实体。每个用户都有一个或多个与之关联的角色。用户的身份通过身份验证过程进行确认，以确保其合法性。
-
角色 roles：核心概念，它代表了一组权限的集合。角色通常根据业务功能或职责进行定义，例如“管理员”、“编辑员”、“访客”等。通过将角色分配给用户，可以实现用户与权限的间接关联，从而简化权限管理。
-
目标 objects：资源或资产，即用户需要访问的实体。目标可以是文件、数据库、设备、服务或任何系统管理的其他资源。每个目标都有与之关联的操作和许可权。
-
操作 operations：对目标进行的特定行为或动作，例如读取、写入、执行、删除等。每个目标都可以定义一组允许的操作，这些操作定义了用户对目标可以执行的行为。
-
许可权 permissions：基本权限单位，它定义了用户对特定目标执行特定操作的授权。许可权通常由角色来赋予，即角色具有一组许可权，用户通过继承角色的许可权来获得对目标和操作的访问权限。
RABC权限模型
在RBAC中，根据权限的复杂程度，又可分为RBAC0、RBAC1、RBAC2、RBAC3。其中，RBAC0是基础，RBAC1、RBAC2、RBAC3都是以RBAC0为基础的升级。
基本模型RABC0
RBAC0是基础，很多产品只需基于RBAC0就可以搭建权限模型了。在这个模型中，我们把权限赋予角色，再把角色赋予用户。用户和角色，角色和权限都是多对多的关系。用户拥有的权限等于他所有的角色持有权限之和。
举例：
譬如我们做一款企业管理产品，如果按传统权限模型，给每一个用户赋予权限则会非常麻烦，并且做不到批量修改用户权限。这时候，可以抽象出几个角色，譬如销售经理、财务经理、市场经理等，然后把权限分配给这些角色，再把角色赋予用户。这样无论是分配权限还是以后的修改权限，只需要修改用户和角色的关系，或角色和权限的关系即可，更加灵活方便。此外，如果一个用户有多个角色，譬如王先生既负责销售部也负责市场部，那么可以给王先生赋予两个角色，即销售经理+市场经理，这样他就拥有这两个角色的所有权限。
角色分层模型RABC1
RBAC1建立在RBAC0基础之上，在角色中引入了继承的概念，有了继承那么角色就有了上下级或者等级关系。类似于树形结构，子角色可以继承父角色的所有权限。
举例：
如果采用RBAC0模型做权限系统，我可能需要为经理、主管、专员分别创建一个角色（角色之间权限无继承性），极有可能出现一个问题，由于权限配置错误，主管拥有经理都没有权限。
RBAC1解决了这个问题，创建完经理角色并配置好权限后，主管角色的权限继承经理角色的权限，并且支持针对性删减主管权限。
角色限制模型RBAC2
RBAC2同样建立在RBAC0基础之上，仅是对用户、角色和权限三者之间增加了一些限制。这些限制可以分成两类，即静态职责分离SSD(Static Separation of Duty)和动态职责分离DSD(Dynamic Separation of Duty)。具体限制如下图：
举例：
还是基于之前RBAC0的例子，我们又发现有些角色之间是需要互斥的，譬如给一个用户分配了销售经理的角色，就不能给他再赋予财务经理的角色了，否则他即可以录入合同又能自己审核合同；再譬如，有些公司对角色的升级十分看重，一个销售员要想升级到销售经理，必须先升级到销售主管，这时候就要采用先决条件限制了。
统一模型RBAC3
RBAC3是RBAC1和RBAC2的合集，所以RBAC3既有角色分层，也包括可以增加各种限制。只有在系统对权限要求非常复杂时，才考虑使用此权限模型。
基于RBAC的延展——用户组
基于RBAC模型，还可以适当延展，使其更适合我们的产品。譬如增加用户组概念，直接给用户组分配角色，再把用户加入用户组。这样用户除了拥有自身的权限外，还拥有了所属用户组的所有权限。
权限框架
- Apache Shrio
- Spring Security
参考资料
2、RBAC模型
3、详细了解RBAC（Role-Based Access Control）
lan.zhihu.com/p/513142061)
1098
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
