从0实现RBAC权限模型从0实现RBAC权限模型

详解 RBAC 基于角色的访问控制（Role-based access control），指的是通过用户的角色（Role）授权其相关权限，这实现了更灵活的访问控制，相比直接授予用户权限，要更加简单、高效、可扩展。
当使用 RBAC 时，通过分析系统用户的实际情况，基于共同的职责和需求，授予他们不同角色。你可以授予给用户一个或多个角色，每个角色具有一个或多个权限，这种用户-角色、角色-权限间的关系，让我们可以不用再单独管理单个用户，用户从授予的角色里面继承所需的权限。
以一个简单的场景（Gitlab 的权限系统）为例，用户系统中有 Admin、Maintainer、Operator 三种角色，这三种角色分别具备不同的权限，比如只有 Admin 具备创建代码仓库、删除代码仓库的权限，其他的角色都不具备。

文章图片

我们授予某个用户「Admin」这个角色，他就具备了「创建代码仓库」和「删除代码仓库」这两个权限。
不直接给用户授权策略，是为了之后的扩展性考虑。比如存在多个用户拥有相同的权限，在分配的时候就要分别为这几个用户指定相同的权限，修改时也要为这几个用户的权限进行一一修改。有了角色后，我们只需要为该角色制定好权限后，给不同的用户分配不同的角色，后续只需要修改角色的权限，就能自动修改角色内所有用户的权限。
比如说，我们准备一个代码审查的角色，只允许查看代码，那么我们只需要添加一个角色“代码审查”，并且赋予其代码查看的权限即可，非常的方便。
要实现 RBAC 模型，一般需要以下实体：
用户 User
基础单位，所有的用户都存储在这里
角色 Role
给相应用户配置对应的角色，和用户是多对多的关系
权限 Permission
权限属于最小的控制判断依据，给对应的角色配置对应的权限，这样拥有此权限的用户就可以访问对应的资源，和角色是多对多的关系
实体关系说明多对多的关系，需要有一个中间表维护关系， User 和 Role 的中间表 User-Role , Role 和 Permission 需要中间表 Role-Permission
场景举例
下面来分析两个具体的应用场景：
现有一个管理系统，简单的分为管理员和普通用户两种角色，管理员具有一些管理权限，但是没有具体业务的权限

文章图片

新增角色这时候需要新增一个角色，主要工作是查看用户的所有反馈，类似于客服的角色，这时候我们只要新增一个角色，并把这个角色配置给某个用户就好了

文章图片

新增权限业务需求，可以给某个用户实施冻结帐户操作，这时候直接添加一个权限，并配置到管理员即可

文章图片

在线体验
使用分支的方式，展示在 vscode 中完成一个 SpringBoot 的 RBAC 鉴权服务的具体过程，可以用来当做一些后台系统的基础模板，可以一步一步的按照顺序结合分支代码进行尝试
在线文档
在线体验