RBAC-基于角色权限的访问控制和基于资源的权限访问控制

RBAC-基于角色权限的访问控制

RBAC-基于角色权限的访问控制和基于资源的权限访问控制_第1张图片

我们开发一个系统,必然面临权限控制的问题,即不同的用户具有不同的访问、操作、数据权限。形成理论的权限控制模型有:自主访问控制(DAC:
Discretionary Access Control)、强制访问控制(MAC: Mandatory Access
Control)、基于属性的权限验证(ABAC: Attribute-Based Access
Control)等。最常被开发者使用也是相对易用、通用的就是RBAC权限模型(Role-Based Access
Control),本文就将向大家介绍该权限模型。

一、RBAC权限模型简介

RBAC权限模型(Role-Based Access Control)即:基于角色的权限控制。模型中有几个关键的术语:

用户:系统接口及访问的操作者

权限:能够访问某接口或者做某操作的授权资格

角色:具有一类相同操作权限的用户的总称

RBAC权限模型核心授权逻辑如下

某用户是什么角色? 你是谁

某角色具有什么权限? 你可以干什么

通过角色的权限推导用户的权限,满足三个原则 即最小责任原则,责任分离原则和数据抽象原则。

二、RBAC的演化进程

用户与权限直接关联
RBAC-基于角色权限的访问控制和基于资源的权限访问控制_第2张图片

用户与权限直接关联
想到权限控制,人们最先想到的一定是用户与权限直接关联的模式,简单地说就是:某个用户具有某些权限。如图:

  1. 张三具有创建用户和删除用户的权限,所以他可能系统维护人员
  2. 李四具有产品记录管理和销售记录管理权限,所以他可能是一个业务销售人员

这种模型能够清晰的表达用户与权限之间的关系,足够简单。但同时也存在问题

  1. 现在用户是张三、李四,以后随着人员增加,每一个用户都需要重新授权
  2. 或者张三、李四离职,需要针对每一个用户进行多种权限的回收

一个用户拥有一个角色
在实际的团体业务中,都可以将用户分类。比如对于薪水管理系统,通常按照级别分类:经理、高级工程师、中级工程师、初级工程师。也就是按照一定的角色分类,通常具有同一角色的用户具有相同的权限。这样改变之后,就可以将针对用户赋权转换为针对角色赋权。
RBAC-基于角色权限的访问控制和基于资源的权限访问控制_第3张图片
一个用户拥有一个角色
一个用户有一个角色
一个角色有多个操作(菜单)权限
一个操作权限可以属于多个角色

我们可以用下图中的数据库设计模型,描述这样的关系
RBAC-基于角色权限的访问控制和基于资源的权限访问控制_第4张图片

三 页面访问权限与操作权限

页面访问权限:所有系统都是由一个个的页面组成,页面再组成模块,用户是否能看到这个页面的菜单、是否能进入这个页面就称为页面访问权限。

操作权限:用户在操作系统中的任何动作、交互都需要有操作权限,如增删改查等。比如:某个按钮,某个超链接用户是否可以点击,是否应该看见的权限。
RBAC-基于角色权限的访问控制和基于资源的权限访问控制_第5张图片

四、数据权限

数据权限比较好理解,就是某个用户能够访问和操作哪些数据。

通常来说,数据权限由用户所属的组织来确定。比如:生产一部只能看自己部门的生产数据,生产二部只能看自己部门的生产数据;销售部门只能看销售数据,不能看财务部门的数据。而公司的总经理可以看所有的数据。

在实际的业务系统中,数据权限往往更加复杂。非常有可能销售部门可以看生产部门的数据,以确定销售策略、安排计划等。

所以为了面对复杂的需求,数据权限的控制通常是由程序员书写个性化的SQL来限制数据范围的,而不是交给权限模型或者Spring Security或shiro来控制。当然也可以从权限模型或者权限框架的角度去解决这个问题,但适用性有限。


基于资源的权限访问控制RBAC(resource-based access control)

是以资源为中心进行的访问控制,只需要为角色添加权限就可以

区别

  1. 由于基于角色的权限访问控制的角色与权限往往是多对多的关系(比如admin角色可以所有CURD的权限,部门经理角色有Retrieve权限,这就是多对多关系了),如果角色所对应的权限发生变化,那我们所编写的判断逻辑就必须发生改变,可扩展性差
  2. 如果是基于资源的权限访问控制,资源和权限一对一关系比较常见,很多时候资源和权限在数据库中会被合并在一张表中,只需要为资源分配相应的权限。所以一个具体操作对应的权限,只要直接判断用户是否拥有该权限即可,可扩展性强

你可能感兴趣的:(RBAC-基于角色权限的访问控制和基于资源的权限访问控制)