如何基于RBAC设计模型设计权限管理系统

RBAC是一个名称或术语，缩写自四个单词的首字母(基于角色的访问控制)，这意味着基于角色的访问控制。

1.什么是RBAC

RBAC是从四个单词的首字母缩写而来的名称或术语(ROLE-BACCESSCControl)，意思是基于角色的访问控制，将角色与权限.联系起来是基于访问控制的权限设计模型

1.1.RBAC和权限管理系统有什么关系

目前最流行的权限管理系统都是基于RBAC权限设计模型设计的，这是一种策略的权限管理系统，或者说是RBAC权限设计模型的具体实现。

1.2.什么是权限

权限是用户可以访问的资源，包括页面权限、操作权限和数据权限。

例如，在常规的管理系统中，如果用户张三在登录系统后修改了个人信息，那么个人信息页面、修改个人信息的按钮以及他可以看到的个人信息数据都是权限，分别对应页面、操作和数据权限。

1.3.什么是角色

根据我个人的理解，角色是具有特定功能或职责的人或用户。

比如登录管理系统的张三，是公司管理系统的经理，也是管理系统的开发者。那么张三就有两个角色：管理员和开发者。

管理员有管理系统的用户功能，开发人员有开发系统的责任。

1.4.什么是访问控制

访问控制是什么人能干什么事,还是以管理系统为例。

李四是普通用户，没有其他角色，只能修改个人信息。

张三是管理员。他可以修改他的个人信息。同时，他还可能修改李四的个人信息。他还可以添加其他用户和删除其他用户。

李四不能修改张三的个人信息，张三可以修改李四的信息，这是人能做的，也就是访问控制。

1.5.不基于RBAC设计权限管理系统缺点

设计基于用户-权限而不是角色关联权限的访问控制系统有什么问题？

在用户少的管理系统中，比如10人左右的管理系统，张三的管理员可以直接将用户和权限关联起来，工作量不大。只需选择一个用户来检查所需的权限。

假设一个用户有4个权限，两个用户需要检查8次才能完成授权。

但是在实际的企业管理系统中，用户数量比较多，很多都有相同的权限，也就是一个普通的访问权限，有100个权限。如果管理员授权100人，100*100=10000权限，那么他授权的工作量就是非常巨大的,还有手动授权，可能是还会造成遗漏,和耗费时间.

这就引入了“角色”的概念。一个角色可以授予相同的100个普通权限，一个角色可以与100个用户相关联。

管理员只需要将角色交给用户，那么用户就拥有了角色下的所有权限，不仅提高了效率，还大大扩展了设计。

同时，我们取消授权也很简单。比如王五只需要断开王五与普通用户的角色关系，就可以立即取消授权。

2.RBAC模型数据库表设计

2.1.用户角色权限之间的关系

如前所述，一个用户可以有多个角色，一个角色可以有多个权限。因此，从全球角度来看，它们之间的关系是多对多的。

2.2.用户和角色是一对一关系表设计

在实际开发中，对于角色和权限之间的数量关系，角色相对少于权限的数量。对于用户和角色的数量关系，角色的数量相对小于用户的数量。然后我们把它们之间的关系设计成：一个用户一个角色即一对一关系，角色和权限之间是多对多关系.

这就是为什么RBAC设计模型是围绕角色.设计的

设计中需要考虑的点是外键关系.在实际开发中，很少建立真正的外键关系，但是可以通过关联查询建立对应的外键列并连接在一起。

但最重要的一点是，外键FK的维护应该放在大量的当事人身上，比如用户和角色表。事实上，可以肯定的是，角色会越来越少，用户数量肯定会随着时间的推移而变化越来越多。因此，维护用户和角色之间的外键关系是在用户表的一边。

如果你不能理解这一点，你可以。

想想，在公司中让员工记住老板容易还是老板记住员工简单这个例子，很明显员工数肯定多于老板数量，所以肯定是员工记住老板来得容易。

2.3.用户和角色是多对多关系表设计

还有一种表设计是允许一个用户有多个角色，比如前面提到的张三既是管理系统的管理员又是管理系统的开发者。基于这样的使用场景下，如果有多个用户像张三这样，那么就演变成用户和角色是多对多关系，而角色和权限是多对多关系维持不变。

这时候我们只需要在用户和角色之间添加一张中间表，用来维护它们之间的多对多关系即可。不知道你们有没有发觉到，凡是需要建立多对多关系，都需要建立一张中间表来维护。

如果没有发觉，可以回顾以下，上面用户和角色关系是一对一关系的表设计中，角色和权限是不是也是绿色的，它们之间是不是也靠中间表来连接起来。

2.4.RBAC表及字段设计小结

上面只是列出比较常用的两种表设计，并且列出比较关键的字段，在实际开发中，肯定不止这些字段。

比如用户表可能会有创建人，创建时间，更新人，更新时间等等基本信息。

比如权限表可能又可以拓展细分成多张表，划分菜单权限，接口Api权限等表

但只要掌握基础的RBAC设计模型，后面的拓展基本上就依葫芦画瓢，能很好理解上手，只不过需要的是一些时间、以及抽象的经验。

3.RBAC模型划分

前面提到是最基础的RBAC模型，而基于核心概念之上,RBAC还提供了扩展模式。包括RBAC1,RBAC2,RBAC3模型。下面介绍这三种类型

3.1.RBAC1模型

此模型引入了角色继承(Hierarchical Role)概念,即角色具有上下级的关系,角色间的继承关系可分为一般继承关系和受限继承关系。

一般继承关系仅要求角色继承关系是一个绝对偏序关系，允许角色间的多继承。而受限继承关系则进一步要求角色继承关系是一个树结构，实现角色间的单继承。这种设计可以给角色分组和分层，一定程度简化了权限管理工作。

3.2 RBAC2模型

基于核心模型的基础上，进行了角色的约束控制,RBAC2模型中添加了责任分离关系,其规定了权限被赋予角色时，或角色被赋予用户时，以及当用户在某一时刻激活一个角色时所应遵循的强制性规则。责任分离包括静态责任分离和动态责任分离。主要包括以下约束:

• 互斥角色: 同一用户只能分配到一组互斥角色集合中至多一个角色，支持责任分离的原则。互斥角色是指各自权限互相制约的两个角色。

比如财务部有会计和审核员两个角色,他们是互斥角色,那么用户不能同时拥有这两个角色,体现了职责分离原则

• 基数约束: 一个角色被分配的用户数量受限；一个用户可拥有的角色数目受限；同样一个角色对应的访问权限数目也应受限，以控制高级权限在系统中的分配

• 先决条件角色: 即用户想获得某上级角色,必须先获得其下一级的角色

3.3. RBAC3模型

即最全面的权限管理,它是基于RBAC0,将RBAC1和RBAC2进行了整合

4.RBAC落地实现和总结

Apache Shrio和Spring Security都是对RBAC权限设计能提供落地实现的框架，在企业级项目中权限管理系统都有用到，

Apache Shrio比较轻量级，不用配置很多，学习成本较低。

Spring Security是在当下SpringBoot、微服务以及前后端分离流行下，比较热门的的安全认证框架。

两者都值得学习和比较，以便应对不同场景下能够快速选型合适技术，本文也是在我在学习两个框架之时，对RBAC模型觉得比较难理解，所以写下这篇博文，来帮助自己理解之间的关系。

同时也算是一点经验分享给需要学习这两个框架的人，最好在学习两个框架之前能稍微懂RBAC模型才能较好理解里面的知识内容。

5.参考资料

可能是史上最全的权限系统设计 - 知乎 (zhihu.com)