RBAC权限管理模型

RBAC权限管理(Role-Based Access Control基于角色的访问控制)

通过给角色授权，从而将附有权限的角色给予某个用户或者用户组。

传统的权限模型：

RBAC权限模型：

(RBAC0、RBAC1、RBAC2、RBAC3)

相对于直接将权限授予用户个人来说，RBAC权限模型增加了角色，授权会更加的灵活方便。

角色可以理解为一定数量的权限集合，权限的载体。

RBAC0：

RBAC0权限管理的核心部分，其他的版本都是建立在0的基础上的。

RBAC0模型：

简单来说，RBAC0就是一个用户拥有若干角色，每一个角色拥有若干权限。这样，就构造成“用户-角色-权限”的授权模型。在这种模型中，用户与角色之间，角色与权限之间，一般都是多对多的关系。并且将关系作为一个单独的概念来使用，这样可以在关系概念中加入一些其他的属性。

        按照传统的权限模型，我需要给每一个用户进行授权，而且做不到批量修改用户权限，现在我只需要抽象出几个角色，对角色进行授权，然后把角色赋予给用户，这样无论是分配权限还是修改权限，我主需要修改用户和角色的关系，或者角色和权限的关系即可。

RBAC1：(角色分层模型)

        RBAC1建立在RBAC0的基础上，引入了角色继承的概念，就是角色可以分等级了，每个等级权限不同，从而实现更细颗粒度的权限管理。

RBAC1在角色中引入了继承的概念，有了继承那么角色就有了上下级或者等级关系，比如一个部门有正副经理，副经理的权限只有正经理的部分权限，这时候就可以采用RBAC1权限模型。

RBAC2：(角色限制模型)

RBAC2也是在RBAC0的基础上加入了约束的概念，主要引入了静态职责分离以及动态职责分离。

静态职责分离(Static Separation of Duty)

1.互斥角色：同一个用户在两个互斥角色中只能选择一个。例：财务部门中一个用户不可能又是出纳又是会计。

2.基数约束：一个用户拥有的角色是有限的，一个角色拥有的许可也是有限的。例：一个部门可能会有多个副经理，但肯定只有一个总经理。

3.先决条件约束：用户想要获得高级角色，首先必须拥有低级角色。例：想要从程序员升为CTO，

肯定是得从组长—>项目经理—>架构师，不可能让你从最底层越级到最高层。

动态职责分离(Dynamic Separation of Duty)

        动态的限制用户及其拥有的角色。主要动态的决定怎么样计划角色，比如一个用户拥有3个角色，只能激活1个，

个人感觉这个跟SSD的互斥角色相类似，只不过互斥角色是直接禁止出现这种情况，而这个是如果出现这个情况而做出的限制。

RBAC3：

RBAC3是RBAC1和RBAC2的合集，所以RBAC3既有角色分层，也包括可以增加各种限制。

RBAC用户组：

     基于RBAC模型，还可以适当延展，使其更适合我们的产品。譬如增加用户组概念，直接给用户组分配角色，再把用户加入用户组。

这样用户除了拥有自身的权限外，还拥有了所属用户组的所有权限。

先说一下为什么要有用户组的概念，如果有一类的用户都要属于某个角色，我们一个个给用户授予角色，重复工作特别多，所以我们把这么一些用户进行分类，也就是用户组，这样的话，我们直接对用户组赋予角色，减少重复的工作量，这样达到的目的是这，用户拥有的所有许可，就是用户个人所属角色拥有的许可与该用户所在用户组所属角色拥有的许可之和。一个用户可以属于多个用户组，一个用户组也可以包括多个用户，所以用户与用户组是多对多的关系。

角色与用户组有何区别

两者的区别在于，用户组是用户的集合，但不是权限的集合，而角色则是同时拥有用户集合以及权限集合。