# admin-spring-boot

**Repository Path**: mbigger/admin-spring-boot

## Basic Information

- **Project Name**: admin-spring-boot
- **Description**: 基于RBAC模型的企业级权限管理系统，使用SpringBoot2开发。
- **Primary Language**: Java
- **License**: Not specified
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 2
- **Forks**: 0
- **Created**: 2019-03-11
- **Last Updated**: 2024-12-10

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# 基于RBAC模型的企业级权限管理系统

### 权限管理系统的分类

#### `ACL`
** 用户-权限： 人员少，功能固定，或者特别简单的系统 **  
访问控制列表，是前几年盛行的一种权限设计，它的核心在于用户直接和权限挂钩。  
由于`ACL`的简单性，使得它很容易实现。但同时它的缺点也是很明显的，由于需要维护大量的访问权限列表，ACL在性能上有明显的缺陷。另外，对于拥有大量用户与众多权限的应用，管理访问控制列表本身就变成非常繁重的工作。 

#### `RBAC`
** 用户-角色-权限： 使得访问控制，特别是对用户的授权管理变得非常简单和易于维护，因此有广泛的应用 ** 
 
![RBAC](/images/rbac.jpg)

`RBAC`是把用户按角色进行归类，通过用户的角色来确定用户能否针对某项资源进行某项操作。`RBAC`相对于ACL最大的优势就是它简化了用户与权限的管理，通过对用户进行分类，使得角色与权限关联起来，而用户与权限变成了间接关联。
但是它也有自身的缺点，那就是由于权限是以角色为载体分配的，如果某一角色下的个别用户需要进行特别的权限定制，如同加入一些其他角色的小部分权限或去除当前角色的一些权限时，`RBAC`就无能为力了，因为`RBAC`对权限的分配是角色为单位的。

### 权限系统与`RBAC`模型概述
在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`模型的实现细节有关。

权限，可分为** 功能级权限 **和 ** 数据级权限 **两种，在系统中，两种权限应当同时有效。例如，在windows系统中，某用户具有新建一个文件的功能权限，该用户在C盘没有写权限，但在D盘有写权限；则该用户不能把他创建的文件保存在C盘而只能保存在D盘。

在上述例子中，能否创建文件是由功能权限来控制的，能否保存文件是由数据权限进行控制的。只有两者同时有效，用户的业务才能顺利进行。

简单地说，权限管理就是对资源的管理。权限管理的目的就是建立分配资源的规则，以便用户能够通过这套规则，获取他们应该获得的资源。

### RBAC用户角色权限设计方案

![数据表设计](/images/module.png)