RBAC(Role-Based Access Control)
这可能是史上最全的权限系统设计
https://mp.weixin.qq.com/s/rB4ODLew6cyWM5d46Gn-lg
前言
权限管理是所有后台系统的都会涉及的一个重要组成部分，主要目的是对不同的人访问资源进行权限的控制，避免因权限控制缺失或操作不当引发的风险问题，如操作错误，隐私数据泄露等问题。
目前在公司负责权限这块, 所以对权限这块的设计比较熟悉, 公司采用微服务架构, 权限系统自然就独立出来了, 其他业务系统包括商品中心, 订单中心, 用户中心, 仓库系统, 小程序, 多个 APP 等十几个系统和终端。
1. 权限模型
迄今为止最为普及的权限设计模型是 RBAC 模型, 基于角色的访问控制（Role-Based Access Control)
1.1 RBAC0 模型
RBAC0 模型如下:
这是权限最基础也是最核心的模型, 它包括用户 / 角色 / 权限, 其中用户和角色是多对多的关系, 角色和权限也是多对多的关系。
用户是发起操作的主体, 按类型分可分为 2B 和 2C 用户, 可以是后台管理系统的用户, 可以是 OA 系统的内部员工, 也可以是面向 C 端的用户, 比如阿里云的用户。
角色起到了桥梁的作用, 连接了用户和权限的关系, 每个角色可以关联多个权限, 同时一个用户关联多个角色, 那么这个用户就有了多个角色的多个权限。
有人会问了为什么用户不直接关联权限呢？在用户基数小的系统, 比如 20 个人的小系统，管理员可以直接把用户和权限关联，工作量并不大，选择一个用户勾选下需要的权限就完事了。
但是在实际企业系统中，用户基数比较大, 其中很多人的权限都是一样的，就是个普通访问权限，如果管理员给 100 人甚至更多授权, 工作量巨大。
这就引入了 "角色 (Role)" 概念, 一个角色可以与多个用户关联, 管理员只需要把该角色赋予用户, 那么用户就有了该角色下的所有权限, 这样设计既提升了效率, 也有很大的拓展性。
- 权限：
是用户可以访问的资源, 包括页面权限, 操作权限, 数据权限:
- 页面权限:
即用户登录系统可以看到的页面, 由菜单来控制, 菜单包括一级菜单和二级菜单, 只要用户有一级和二级菜单的权限, 那么用户就可以访问页面
- 操作权限:
即页面的功能按钮，包括查看, 新增, 修改, 删除, 审核等，用户点击删除按钮时，后台会校验用户角色下的所有权限是否包含该删除权限。如果是, 就可以进行下一步操作, 反之提示无权限。
有的系统要求 "可见即可操作", 意思是如果页面上能够看到操作按钮, 那么用户就可以操作, 要实现此需求, 这里就需要前端来配合, 前端开发把用户的权限信息缓存, 在页面判断用户是否包含此权限, 如果有, 就显示该按钮, 如果没有, 就隐藏该按钮。
某种程度上提升了用户体验, 但是在实际场景可自行选择是否需要这样做
- 数据权限:
数据权限就是用户在同一页面看到的数据是不同的，比如财务部只能看到其部门下的用户数据，采购部只看采购部的数据。
在一些大型的公司，全国有很多城市和分公司，比如杭州用户登录系统只能看到杭州的数据，上海用户只能看到上海的数据，解决方案一般是把数据和具体的组织架构关联起来。
举个例子, 再给用户授权的时候, 用户选择某个角色同时绑定组织如财务部或者合肥分公司, 那么该用户就有了该角色下财务部或合肥分公司下的的数据权限。
以上是 RBAC 的核心设计及模型分析, 此模型也叫做 RBAC0, 而基于核心概念之上, RBAC 还提供了扩展模式。包括 RBAC1,RBAC2,RBAC3 模型。下面介绍这三种类型
1.2 RBAC1 模型
此模型引入了角色继承 (Hierarchical Role) 概念，即角色具有上下级的关系，角色间的继承关系可分为一般继承关系和受限继承关系。
一般继承关系仅要求角色继承关系是一个绝对偏序关系，允许角色间的多继承。
而受限继承关系则进一步要求角色继承关系是一个树结构，实现角色间的单继承。这种设计可以给角色分组和分层，一定程度简化了权限管理工作。
1.3 RBAC2 模型
基于核心模型的基础上，进行了角色的约束控制，RBAC2 模型中添加了责任分离关系。
其规定了权限被赋予角色时，或角色被赋予用户时，以及当用户在某一时刻激活一个角色时所应遵循的强制性规则。
责任分离包括静态责任分离和动态责任分离。主要包括以下约束:
- 互斥角色:
同一用户只能分配到一组互斥角色集合中至多一个角色，支持责任分离的原则。
互斥角色是指各自权限互相制约的两个角色。比如财务部有会计和审核员两个角色, 他们是互斥角色, 那么用户不能同时拥有这两个角色, 体现了职责分离原则
- 基数约束:
一个角色被分配的用户数量受限；一个用户可拥有的角色数目受限；同样一个角色对应的访问权限数目也应受限，以控制高级权限在系统中的分配
- 先决条件角色:
即用户想获得某上级角色, 必须先获得其下一级的角色
1.4 RBAC3 模型
即最全面的权限管理, 它是基于 RBAC0，将 RBAC1 和 RBAC2 进行了整合。
1.5 用户组
当平台用户基数增大，角色类型增多时，而且有一部分人具有相同的属性，比如财务部的所有员工，如果直接给用户分配角色，管理员的工作量就会很大。
如果把相同属性的用户归类到某用户组，那么管理员直接给用户组分配角色，用户组里的每个用户即可拥有该角色，以后其他用户加入用户组后，即可自动获取用户组的所有角色，退出用户组，同时也撤销了用户组下的角色，无须管理员手动管理角色。
根据用户组是否有上下级关系, 可以分为有上下级的用户组和普通用户组:
- 具有上下级关系的用户组:
最典型的例子就是部门和职位，可能多数人没有把部门职位和用户组关联起来吧。
当然用户组是可以拓展的，部门和职位常用于内部的管理系统，如果是面向 C 端的系统。
比如淘宝网的商家，商家自身也有一套组织架构，比如采购部，销售部，客服部，后勤部等，有些人拥有客服权限，有些人拥有上架权限等等，所以用户组是可以拓展的
- 普通用户组:
即没有上下级关系，和组织架构，职位都没有关系，也就是说可以跨部门，跨职位。
举个例子，某电商后台管理系统，有拼团活动管理角色，我们可以设置一个拼团用户组，该组可以包括研发部的后台开发人员，运营部的运营人员，采购部的人员等等。
每个公司都会涉及到到组织和职位, 下面就重点介绍这两个。
1.5.1 组织
常见的组织架构如下图:
我们可以把组织与角色进行关联，用户加入组织后，就会自动获得该组织的全部角色，无须管理员手动授予，大大减少工作量，同时用户在调岗时，只需调整组织，角色即可批量调整。
组织的另外一个作用是控制数据权限, 把角色关联到组织, 那么该角色只能看到该组织下的数据权限。
1.5.2 职位
假设财务部的职位如下图:
每个组织部门下都会有多个职位，比如财务部有总监，会计，出纳等职位，虽然都在同一部门，但是每个职位的权限是不同的，职位高的拥有更多的权限。
总监拥有所有权限，会计和出纳拥有部分权限。特殊情况下, 一个人可能身兼多职。
1.6 含有组织 / 职位 / 用户组的模型
根据以上场景, 新的权限模型就可以设计出来了, 如下图:
根据系统的复杂度不同, 其中的多对多关系和一对一关系可能会有变化
1、在单系统且用户类型单一的情况下，用户和组织是一对一关系，组织和职位是一对多关系，用户和职位是一对一关系，组织和角色是一对一关系，职位和角色是一对一关系，用户和用户组是多对对关系，用户组和角色是一对一关系，当然这些关系也可以根据具体业务进行调整。
模型设计并不是死的, 如果小系统不需要用户组, 这块是可以去掉的。
2、分布式系统且用户类型单一的情况下，到这里权限系统就会变得很复杂，这里就要引入了一个 "系统" 概念。
3、此时系统架构是个分布式系统，权限系统独立出来，负责所有的系统的权限控制，其他业务系统比如商品中心，订单中心，用户中心，每个系统都有自己的角色和权限，那么权限系统就可以配置其他系统的角色和权限。
4、分布式系统且用户类型多个的情况下，比如淘宝网，它的用户类型包括内部用户，商家，普通用户，内部用户登录多个后台管理系统，商家登录商家中心，这些做权限控制，如果你作为架构师，该如何来设计呢? 大神可以在评论区留言交流哦!
2. 授权流程
授权即给用户授予角色, 按流程可分为手动授权和审批授权。权限中心可同时配置这两种, 可提高授权的灵活性。
- 手动授权:
管理员登录权限中心为用户授权，根据在哪个页面授权分为两种方式：给用户添加角色，给角色添加用户。
给用户添加角色就是在用户管理页面，点击某个用户去授予角色，可以一次为用户添加多个角色；给角色添加用户就是在角色管理页面，点击某个角色，选择多个用户，实现了给批量用户授予角色的目的。
- 审批授权:
即用户申请某个职位角色，那么用户通过 OA 流程申请该角色，然后由上级审批，该用户即可拥有该角色，不需要系统管理员手动授予。
3. 表结构
有了上述的权限模型, 设计表结构就不难了, 下面是多系统下的表结构, 简单设计下, 主要提供思路:
4. 权限框架
- Apache Shrio
- Spring Security
在项目中可以采用其中一种框架, 它们的优缺点以及如何使用会在后面的文章中详细介绍。
5. 结语
权限系统可以说是整个系统中最基础，同时也可以很复杂的，在实际项目中，会遇到多个系统，多个用户类型，多个使用场景，这就需要具体问题具体分析，但最核心的 RBAC 模型是不变的, 我们可以在其基础上进行扩展来满足需求。
权限系统与RBAC模型概述[绝对经典]
原文链接：https://blog.csdn.net/yangwenxue_admin/article/details/73936803
[TOC]
0.前言
一年前，我负责的一个项目中需要权限管理。当时凭着自己的逻辑设计出了一套权限管理模型，基本原理与RBAC非常相似，只是过于简陋。当时google了一些权限管理的资料，从中了解到早就有了RBAC这个东西。可惜一直没狠下心来学习。
更详细的RBAC模型非常复杂。本文只做了一些基础的理论性概述。本文资料完全来自互联网。
1.权限系统与RBAC模型概述
RBAC（Role-Based Access Control ）基于角色的访问控制。
在20世纪90年代期间，大量的专家学者和专门研究单位对RBAC的概念进行了深入研究，先后提出了许多类型的RBAC模型，其中以美国George Mason大学信息安全技术实验室（LIST）提出的RBAC96模型最具有系统性，得到普遍的公认。
RBAC认为权限的过程可以抽象概括为：判断【Who是否可以对What进行How的访问操作（Operator）】这个逻辑表达式的值是否为True的求解过程。
即将权限问题转换为Who、What、How的问题。who、what、how构成了访问权限三元组。
RBAC支持公认的安全原则：最小特权原则、责任分离原则和数据抽象原则。
- 最小特权原则得到支持，是因为在RBAC模型中可以通过限制分配给角色权限的多少和大小来实现，分配给与某用户对应的角色的权限只要不超过该用户完成其任务的需要就可以了。
- 责任分离原则的实现，是因为在RBAC模型中可以通过在完成敏感任务过程中分配两个责任上互相约束的两个角色来实现，例如在清查账目时，只需要设置财务管理员和会计两个角色参加就可以了。
- 数据抽象是借助于抽象许可权这样的概念实现的，如在账目管理活动中，可以使用信用、借方等抽象许可权，而不是使用操作系统提供的读、写、执行等具体的许可权。但RBAC并不强迫实现这些原则，安全管理员可以允许配置RBAC模型使它不支持这些原则。因此，RBAC支持数据抽象的程度与RBAC模型的实现细节有关。
RBAC96是一个模型族，其中包括RBAC0~RBAC3四个概念性模型。
-
基本模型RBAC0定义了完全支持RBAC概念的任何系统的最低需求。
-
RBAC1和RBAC2两者都包含RBAC0，但各自都增加了独立的特点，它们被称为高级模型。
RBAC1中增加了角色分级的概念，一个角色可以从另一个角色继承许可权。
RBAC2中增加了一些限制，强调在RBAC的不同组件中在配置方面的一些限制。
- RBAC3称为统一模型，它包含了RBAC1和RBAC2，利用传递性，也把RBAC0包括在内。这些模型构成了RBAC96模型族。
2.RBAC模型简述
RBAC0的模型中包括用户（U）、角色（R）和许可权（P）等3类实体集合。
RABC0权限管理的核心部分，其他的版本都是建立在0的基础上的，看一下类图：
RBAC0定义了能构成一个RBAC控制系统的最小的元素集合。
在RBAC之中,包含用户users(USERS)、角色roles(ROLES)、目标objects(OBS)、操作operations(OPS)、许可权permissions(PRMS)五个基本数据元素，此模型指明用户、角色、访问权限和会话之间的关系。
每个角色至少具备一个权限，每个用户至少扮演一个角色；可以对两个完全不同的角色分配完全相同的访问权限；会话由用户控制，一个用户可以创建会话并激活多个用户角色，从而获取相应的访问权限，用户可以在会话中更改激活角色，并且用户可以主动结束一个会话。
用户和角色是多对多的关系，表示一个用户在不同的场景下可以拥有不同的角色。
例如项目经理也可以是项目架构师等；当然了一个角色可以给多个用户，例如一个项目中有多个组长，多个组员等。
这里需要提出的是，将用户和许可进行分离，是彼此相互独立，使权限的授权认证更加灵活。
角色和许可（权限）是多对多的关系，表示角色可以拥有多分权利，同一个权利可以授给多个角色都是非常容易理解的，想想现实生活中，当官的级别不同的权限的情景，其实这个模型就是对权限这方面的一个抽象，联系生活理解就非常容易了。
RBAC1，基于RBAC0模型，引入角色间的继承关系，即角色上有了上下级的区别，角色间的继承关系可分为一般继承关系和受限继承关系。一般继承关系仅要求角色继承关系是一个绝对偏序关系，允许角色间的多继承。而受限继承关系则进一步要求角色继承关系是一个树结构，实现角色间的单继承。
这种模型合适于角色之间的层次明确，包含明确。
RBAC2，基于RBAC0模型的基础上，进行了角色的访问控制。
RBAC2模型中添加了责任分离关系。RBAC2的约束规定了权限被赋予角色时，或角色被赋予用户时，以及当用户在某一时刻激活一个角色时所应遵循的强制性规则。责任分离包括静态责任分离和动态责任分离。约束与用户-角色-权限关系一起决定了RBAC2模型中用户的访问许可，此约束有多种。
- 互斥角色 ：同一用户只能分配到一组互斥角色集合中至多一个角色，支持责任分离的原则。互斥角色是指各自权限互相制约的两个角色。对于这类角色一个用户在某一次活动中只能被分配其中的一个角色，不能同时获得两个角色的使用权。常举的例子：在审计活动中，一个角色不能同时被指派给会计角色和审计员角色。
- 基数约束 ：一个角色被分配的用户数量受限；一个用户可拥有的角色数目受限；同样一个角色对应的访问权限数目也应受限，以控制高级权限在系统中的分配。例如公司的领导人有限的；
- 先决条件角色 ：可以分配角色给用户仅当该用户已经是另一角色的成员；对应的可以分配访问权限给角色，仅当该角色已经拥有另一种访问权限。指要想获得较高的权限，要首先拥有低一级的权限。就像我们生活中，国家主席是从副主席中选举的一样。
- 运行时互斥 ：例如，允许一个用户具有两个角色的成员资格，但在运行中不可同时激活这两个角色。
RBAC3，也就是最全面级的权限管理，它是基于RBAC0的基础上，将RBAC1和RBAC2进行整合了，最全面，也最复杂的：
综上为权限管理模型的相关介绍，其实在任何系统中都会涉及到权限管理的模块，无论复杂简单，我们都可以通过以RBAC模型为基础，进行相关灵活运用来解决我们的问题。
3.RBAC的优缺点
RBAC模型没有提供操作顺序控制机制。这一缺陷使得RBAC模型很难应用关于那些要求有严格操作次序的实体系统。
例如，在购物控制系统中要求系统对购买步骤的控制，在客户未付款之前不应让他把商品拿走。RBAC模型要求把这种控制机制放到模型里面。
4.实用的RBAC模型的数据库建模
以下模型均来自于互联网
1.扩展RBAC用户角色权限设计方案
RBAC（Role-Based Access Control，基于角色的访问控制），就是用户通过角色与权限进行关联。简单地说，一个用户拥有若干角色，每一个角色拥有若干权限。这样，就构造成“用户-角色-权限”的授权模型。在这种模型中，用户与角色之间，角色与权限之间，一般是多对多的关系。（如下图）
角色是什么？可以理解为一定数量的权限的集合，权限的载体。例如：一个论坛系统，“超级管理员”、“版主”都是角色。版主可管理版内的帖子、可管理版内的用户等，这些是权限。要给某个用户授予这些权限，不需要直接将权限授予用户，可将“版主”这个角色赋予该用户。
当用户的数量非常大时，要给系统每个用户逐一授权（授角色），是件非常烦琐的事情。这时，就需要给用户分组，每个用户组内有多个用户。除了可给用户授权外，还可以给用户组授权。这样一来，用户拥有的所有权限，就是用户个人拥有的权限与该用户所在用户组拥有的权限之和。（下图为用户组、用户与角色三者的关联关系）
在应用系统中，权限表现成什么？对功能模块的操作，对上传文件的删改，菜单的访问，甚至页面上某个按钮、某个图片的可见性控制，都可属于权限的范畴。有些权限设计，会把功能操作作为一类，而把文件、菜单、页面元素等作为另一类，这样构成“用户-角色-权限-资源”的授权模型。而在做数据表建模时，可把功能操作和资源统一管理，也就是都直接与权限表进行关联，这样可能更具便捷性和易扩展性。（见下图）
请留意权限表中有一列“权限类型”，我们根据它的取值来区分是哪一类权限，如“MENU”表示菜单的访问权限、“OPERATION”表示功能模块的操作权限、“FILE”表示文件的修改权限、“ELEMENT”表示页面元素的可见性控制等。
这样设计的好处有二。其一，不需要区分哪些是权限操作，哪些是资源，（实际上，有时候也不好区分，如菜单，把它理解为资源呢还是功能模块权限呢？）。其二，方便扩展，当系统要对新的东西进行权限控制时，我只需要建立一个新的关联表“权限XX关联表”，并确定这类权限的权限类型字符串。
这里要注意的是，权限表与权限菜单关联表、权限菜单关联表与菜单表都是一对一的关系。（文件、页面权限点、功能操作等同理）。也就是每添加一个菜单，就得同时往这三个表中各插入一条记录。这样，可以不需要权限菜单关联表，让权限表与菜单表直接关联，此时，须在权限表中新增一列用来保存菜单的ID，权限表通过“权限类型”和这个ID来区分是种类型下的哪条记录。
到这里，RBAC权限模型的扩展模型的完整设计图如下：
随着系统的日益庞大，为了方便管理，可引入角色组对角色进行分类管理，跟用户组不同，角色组不参与授权。例如：某电网系统的权限管理模块中，角色就是挂在区局下，而区局在这里可当作角色组，它不参于权限分配。另外，为方便上面各主表自身的管理与查找，可采用树型结构，如菜单树、功能树等，当然这些可不需要参于权限分配。
2.百度百科所示的模型
3.本文参考文献中的一种设计
5.辨析：角色与用户组有何区别？
两者的主要差别是：用户组是用户的集合，但不是许可权的集合；而角色却同时具有用户集合和许可权集合的概念，角色的作用把这两个集合联系在一起的中间媒介。
在一个系统中，如果用户组的许可权和成员仅可以被系统安全员修改的话，在这种机制下，用户组的机制是非常接近于角色的概念的。角色也可以在用户组的基础上实现，这有利于保持原有系统中的控制关系。在这种情况下，角色相当于一个策略部件，与用户组的授权及责任关系相联系，而用户组是实现角色的机制，因此，两者之间是策略与实现机制之间的关系。
6.ACL模型
访问控制列表，是前几年盛行的一种权限设计，它的核心在于用户直接和权限挂钩。
RBAC的核心是用户只和角色关联，而角色代表对了权限，这样设计的优势在于使得对用户而言，只需角色即可以，而某角色可以拥有各种各样的权限并可继承。
ACL和RBAC相比，缺点在于由于用户和权限直接挂钩，导致在授予时的复杂性，虽然可以利用组来简化这个复杂性，但仍然会导致系统不好理解，而且在取出判断用户是否有该权限时比较的困难，一定程度上影响了效率。
7.基于RBAC模型的权限验证框架与应用
- Apache Shiro
- spring Security
- SELinux
8.RBAC参考文献
发表评论