图文详解基于角色的权限控制模型RBAC

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

1、RBAC权限模型简介

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

• 用户：系统接口及访问的操做者
• 权限：可以访问某接口或者作某操做的受权资格
• 角色：具备一类相同操做权限的用户的总称

RBAC权限模型核心受权逻辑以下：

• 某用户是什么角色？
• 某角色具备什么权限？
• 经过角色的权限推导用户的权限

2、RBAC的演化进程

2.1.用户与权限直接关联

想到权限控制，人们最早想到的必定是用户与权限直接关联的模式，简单地说就是：某个用户具备某些权限。如图：

• 张三具备建立用户和删除用户的权限，因此他可能系统维护人员
• 李四具备产品记录管理和销售记录管理权限，因此他多是一个业务销售人员

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

• 如今用户是张3、李四，之后随着人员增长，每个用户都须要从新受权
• 或者张3、李四离职，须要针对每个用户进行多种权限的回收

2.2.一个用户拥有一个角色

在实际的团体业务中，均可以将用户分类。好比对于薪水管理系统，一般按照级别分类：经理、高级工程师、中级工程师、初级工程师。也就是按照必定的角色分类，一般具备同一角色的用户具备相同的权限。这样改变以后，就能够将针对用户赋权转换为针对角色赋权。

• 一个用户有一个角色
• 一个角色有多个操做（菜单）权限
• 一个操做权限能够属于多个角色

咱们能够用下图中的数据库设计模型，描述这样的关系。

2.3 一个用户一个或多个角色

可是在实际的应用系统中，一个用户一个角色远远知足不了需求。若是咱们但愿一个用户既担任销售角色、又暂时担任副总角色。该怎么作呢？为了增长系统设计的适用性，咱们一般设计：

• 一个用户有一个或多个角色
• 一个角色包含多个用户
• 一个角色有多种权限
• 一个权限属于多个角色

咱们能够用下图中的数据库设计模型，描述这样的关系。

2、页面访问权限与操做权限

• 页面访问权限: 全部系统都是由一个个的页面组成，页面再组成模块，用户是否能看到这个页面的菜单、是否能进入这个页面就称为页面访问权限。
• 操做权限： 用户在操做系统中的任何动做、交互都须要有操做权限，如增删改查等。好比：某个按钮，某个超连接用户是否能够点击，是否应该看见的权限。

为了适应这种需求，咱们能够把页面资源(菜单)和操做资源(按钮)分表存放，如上图。也能够把两者放到一个表里面存放，用一个字段进行标志区分。

3、数据权限

数据权限比较好理解，就是某个用户可以访问和操做哪些数据。

• 一般来讲，数据权限由用户所属的组织来肯定。好比：生产一部只能看本身部门的生产数据，生产二部只能看本身部门的生产数据；销售部门只能看销售数据，不能看财务部门的数据。而公司的总经理能够看全部的数据。
• 在实际的业务系统中，数据权限每每更加复杂。很是有可能销售部门能够看生产部门的数据，以肯定销售策略、安排计划等。

因此为了面对复杂的需求，数据权限的控制一般是由程序员书写个性化的SQL来限制数据范围的，而不是交给权限模型或者Spring Security或shiro来控制。固然也能够从权限模型或者权限框架的角度去解决这个问题，但适用性有限。

期待您的关注

• 向您推荐博主的系列文档：《手摸手教您学习SpringBoot系列-16章97节》
• 本文转载注明出处（必须带链接，不能只转文字）：字母哥博客。