📝个页人主：五敷有你      
 🔥系列专栏：SpringBoot
⛺️稳重求进，晒太阳

权限系统与RBAC模型

权限

为了解决用户和资源的操作关系， 让指定的用户，只能操作指定的资源。

权限功能

• 菜单权限：某用户，某角色能看到某菜单，例如：超管能看到所有的菜单，普通员工只能看到请假菜单。
  • 粒度细的话可以做到按钮、标签显示不显示，字段显示不显示等，
  • 主要是前端的事情。具体实现可以将权限存在session中，用一些v-if 标签进行判断 有就生成没有就忽略
• 接口权限：某用户，某角色能操作某接口，例如：超管能操作所有按钮接口，普通用户只能操作提交请假，查看请求列表。
  • 因为上面的操作是可以把按钮隐掉了，一部分小白是操作不了相关操作，但是如果另一个码农知道了你的接口，就可以使用接口模拟操作了。
  • 主要是后端的事情（鉴权）。
• 数据权限，某用户，某角色能查看某数据，例如：超管能看到所有人的请假单，普通用户只能看到自己的请假单
  • 例如查看工资条接口，这个接口权限都能调用，但是工资条肯定只能看到自己的，超过可以看到所有人的。这里数据权限体会下。
  • 能crud哪些数据。
  • 能看到哪些字段。
  • 主要是后端的事情

RBAC权限系统

概述

通常情况下，一个系统，除了登陆也就是认证之外，还应该有一个重要的功能，就是鉴权，使用rbac可以很好的解决上述的问题。

• 认证(authentication)-规定了谁能够登陆
• 鉴权(authorization)-规定了谁能访问那些接口，浏览那些页面，使用哪些功能，

RBAC（Role-Based Access Control ）基于角色的访问控制。

不同人，有不同的权限，老师有判卷权限，学生有答题的权限...

RBAC语言中的角色通常是指一组具有某些特征的人，例如:部门 /地点/资历/工作职责等

RBAC认为权限的过程可以抽象概括为：

判断【Who是否可以对What进行How的访问操作（Operator）】这个逻辑表达式的值是否为True的求解过程。

即将权限问题转换为Who、What、How的问题。who、what、how构成了访问权限三元组。

定义角色后,就要分配权限，可能涉及如下：

Access(访问)，这个人能看到什么

• 访问表示用户可以查看或访问系统中哪些资源。这决定了用户对特定数据或功能的可见性。在RBAC中，可以通过角色分配访问权限，使得一组用户共享相似的访问能力。
• 例如，在文件系统中，访问可以控制用户能够访问哪些文件或目录。在应用程序中，访问可以决定用户是否能够查看特定页面或功能。

Operations(操作)，这个人能读到什么，这个人能写什么，该人可以创建和删除文件吗？

• 操作定义了用户对其拥有访问权限资源可以执行的具体动作。这包括了读取、写入、删除、创建等各种可能的操作。通过将操作与访问权限关联，RBAC提供了对用户行为更细粒度的控制。
• 例如，在数据库中，操作可能包括查询、更新、删除或插入记录。在文件系统中，操作可以确定用户是否能够执行文件的特定操作，如复制、移动或重命名。

Session(会话)，该人可以在系统中停留多长时间，，什么时候可以登录，登录什么时候过期

• 会话管理用户在系统中的停留时间以及与身份验证和授权相关的时间参数。这包括了用户何时可以登录系统、登录会话的持续时间，以及在什么条件下会话可能被终止。
• 通过对会话进行有效管理，可以提高系统的安全性，防止未经授权的访问，并确保合规性。会话设置可以包括过期时间、自动注销等策略，以控制用户在系统中的活动时间。

RBAC分为了四级

第0级，扁平化，最简单也是最常用的RBAC形式，与员工使用角色获得权限

第1级，分层的，这建立在Flat RBAC 规则之上，增加了角色层次结构

比如销售有销售经理，销售总监，销售的普通人员，都是销售但是级别不一样。

第2级别，受约束的,这建立在分层RBAC之上，增加了职责分离

第3级别，对称的，建立在受约束的RBAC模型之上，并增加了权限审查

RBAC支持公认的安全原则：

最小特权原则、责任分离原则和数据抽象原则。

• 最小特权原则得到支持：是因为在RBAC模型中可以通过限制分配给角色权限的多少和大小来实现，分配给与某用户对应的角色的权限只要不超过该用户完成其任务的需要就可以了。
• 责任分离原则的实现：是因为在RBAC模型中可以通过在完成敏感任务过程中分配两个责任上互相约束的两个角色来实现，例如在清查账目时，只需要设置财务管理员和会计两个角色参加就可以了。
• 数据抽象：借助于抽象许可权这样的概念实现的，如在账目管理活动中，可以使用信用、借方等抽象许可权，而不是使用操作系统提供的读、写、执行等具体的许可权。但RBAC并不强迫实现这些原则，安全管理员可以允许配置RBAC模型使它不支持这些原则。因此，RBAC支持数据抽象的程度与RBAC模型的实现细节有关。

RBAC的组成

在RBAC模型里面，有3个基础组成部分，分别是：用户、角色和权限。

RBAC通过定义角色的权限，并对用户授予某个角色从而来控制用户的权限，实现了用户和权限的逻辑分离（区别于ACL模型），极大地方便了权限的管理

在讲解之前，我们先介绍一些名词：

• User（用户）：每个用户都有唯一的UID识别，并被授予不同的角色
• Role（角色）：不同角色具有不同的权限，比如：人事、会计等
• Permission（权限）：访问权限，比如
• 用户-角色映射：用户和角色之间的映射关系
• 角色-权限映射：角色和权限之间的映射

它们之间的关系如下图所示：

例如下图，管理员和普通用户被授予不同的权限，普通用户只能去修改和查看个人信息，而不能创建用户和冻结用户，而管理员由于被授予所有权限，所以可以做所有操作。

rbac说明图

完成RBAC模型，我们需要设计五张表，如下：

.