avatar

RBAC权限模型

前言

权限对于每个系统都非常重要,现有的系统的权限管理基本都是基于RBAC来实现的,所以我们应该学习RBAC。

什么是RBAC模型

RBAC是Role-Based Access Control的英文缩写,意思是基于角色的访问控制。
RBAC认为权限授权实际上是Who、What、How的问题。在RBAC模型中,who、what、how构成了访问权限三元组,也就是“Who对What(Which)进行How的操作,也就是“主体”对“客体”的操作,其中who——是权限的拥有者或主体(如:User、Role),what——是资源或对象(Resource、Class)

RBAC其实是一种分析模型,主要分为:

  • 基本模型RBAC0(Core RBAC)
  • 角色分层模型RBAC1(Hierarchal RBAC)
  • 角色限制模型RBAC2(Constraint RBAC)
  • 统一模型RBAC3(Combines RBAC)。

RBAC0

RBAC0,它是RBAC的核心,RBAC1、RBAC2、RBAC3都是先后在RBAC0上的扩展。RBAC0定义了能构成RBAC控制系统的最小的元素集合,RBAC0由四部分构成:

  • 用户(User)
  • 角色(Role)
  • 会话(Session)
  • 许可(Pemission)

其中许可又包括“操作”和“控制对象”其中许可被赋予角色,而不是用户,当一个角色被指定给一个用户时,此用户就拥有了该角色所包含的许可。会话是动态的概念,用户必须通过会话才可以设置角色,是用户与激活的角色之间的映射关系。

RBAC0

图中,用户与角色是多对多的关系;角色和许可也是多对多的关系;用户与会话是一对一关系;会话与角色是一对多关系;

RBAC1

RBAC1,它是RBAC角色的分层模型,RBAC1建立在RBAC0基础之上,在角色中引入了继承的概念,有了继承那么角色就有了上下级或者等级关系,角色间的继承关系可分为一般继承关系和受限继承关系。一般继承关系仅要求角色继承关系是一个绝对偏序关系,允许角色间的多继承。而受限继承关系则进一步要求角色继承关系是一个树结构,实现角色间的单继承。

这种模型合适于角色之间的层次明确,包含明确。
RBAC1

RBAC2

RBAC2,它是RBAC的约束模型,RBAC2也是建立的RBAC0的基础之上的,在RBAC0基础上假如了约束的概念,主要引入了静态职责分离SSD(Static Separation of Duty)和动态职责分离DSD(Dynamic Separation of Duty)。

SSD是用户和角色的指派阶段加入的,主要是对用户和角色有如下约束:

  • 互斥角色:同一个用户在两个互斥角色中只能选择一个
  • 基数约束:一个用户拥有的角色是有限的,一个角色拥有的许可也是有限的
  • 先决条件约束:用户想要获得高级角色,首先必须拥有低级角色

DSD是会话和角色之间的约束,可以动态的约束用户拥有的角色,如一个用户可以拥有两个角色,但是运行时只能激活一个角色。

RBAC2

RBAC3

RBAC3,它是RBAC1与RBAC2合集,所以RBAC3是既有角色分层又有约束的一种模型

以上就是RBAC模型的四种设计思想,在使用中根据系统需要做相应的修改。

RBAC新解

有两种正使用的 RBAC 控制方式:隐式(模糊)的方式和显示(明确)的方式

隐式(模糊)的方式

不能明确的知道一个角色到底关联了哪些可执行操作,直接通过角色来验证用户有没有操作权限
例如:“超级管理员”角色能新建用户

if(hasRole("admin")){
// show add user button
}

上面这种权限访问控制是非常脆弱的,一个极小的权限方面的需求变动都可能导致上面的代码需要重新修改
假如:需要新增“部门管理员”角色,也能新增用户

这种方式就是基于角色的访问控制:(Role-Based Access Control)

显示(明确)的方式

明确定义一个角色能对哪些资源进行什么操作
例如:如果当前用户有新建用户的权限则显示新建按钮

// 直接判断是否拥有权限
if(user.hasPermission("user:add")){
// show add user button
}

显式的权限控制方式的好处

更少的代码重构

系统的功能需求一旦确定下来后,一段时间内对它的改动相应还是比较少的。
显式的权限控制方式不会因不同的角色要对功能进行操作而修改功能代码

更直观

保护资源对象、控制对资源对象的操作。
这样的权限控制方式更符合人们的思想习惯。

更有弹性

可支持任何安全模型的设计。
例如:将操作(权限)直接分配给角色,或者将多个角色关联到组(group)上。

外部安全策略管理

资源/行为与用户、组、角色的关联可以通过外部的模块或专用工具或管理控制台来完成

可在运行环境做修改

因为基于资源的权限控制代码并不依赖于行为的主体(如组、角色、用户等)(没有将行为的主体的字符名词写在代码中),所以你甚至可以在程序运行的时候通过修改主体能对资源进行的操作,通过配置的方式就可应对权限方面需求的变动,不需要重构代码。

这种显式的机制带给我们的富有弹性的权限模型。在这种新的模型下,已不必再局限于角色了,你可以将权限直接分配给用户、组或其它对象。

这种方式就是基于资源的访问控制:(Resource-Based Access Control),也就是所谓的RBAC新解。

参考资料

  1. 百科RBAC
  2. 权限系统与RBAC模型概述
文章作者: 毛毛是只猫
文章链接: http://lshaolin.github.io/posts/37cc241/
版权声明: 本博客所有文章除特别声明外,均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来自 毛毛是只猫