本文共 3052 字，大约阅读时间需要 10 分钟。

1.什么是RBAC

RBAC是取自（Role-Based Access Control)四个单词首字母的缩写成的名称或者术语，意思是基于角色访问控制，它是基于角色为核心去关联权限进行访问控制的一种权限设计模型。

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

现在比较普遍的权限管理系统都是基于RBAC权限设计模型进行设计的，RBAC设计模型是权限管理系统的一种策略，或者说权限管理系统是RBAC权限设计模型的具体实现。

1.2.什么是权限

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

举个例子：在常规的管理系统中，用户张三登录系统后对个人信息进行修改，那它能看到的个人信息页面、修改个人信息按钮、个人信息数据这三者都是权限，分别对应页面、操作、数据权限。

1.3.什么是角色

按照我个人理解是角色是拥有特定功能或者承担特定责任的人或者用户。

举个例子：登录管理系统的张三，在公司是管理系统中管理员，同时他又是开发该管理系统的开发者。那么张三拥有管理员、开发者两个角色。

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

1.4.什么是访问控制

访问控制就是什么人能干什么事，还是以管理系统为例子说明。

李四是个普通用户，没有其他角色，那么他只能修改到自己的个人信息。

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

李四不能修改张三个人信息，张三能修改李四信息，这就是什么人能干什么事，也就是访问控制。

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

如果不基于角色关联权限进行访问控制设计权限管理系统，而是基于用户-权限设计访问控制会有什么问题？

在用户数量比较小的管理系统,比如10个人左右的管理系统,张三管理员可以直接把用户和权限关联,工作量并不大,选择一个用户勾选下需要的权限就完事了。

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

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

这就引入了"角色(Role)"概念,一个角色可以授予相同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.参考资料

转载地址：https://www.cnblogs.com/codeluojay/p/15579442.html 如侵犯您的版权，请留言回复原文章的地址，我们会给您删除此文章，给您带来不便请您谅解！