「这是我参与11月更文挑战的第1天，活动详情查看：2021最后一次更文挑战」
1 如何进行权限管理
在web开发中, 权限管理是大部分系统的重中之重, 也是每位开发人员最头疼的内容之一
当下常用的权限解决方案有:
- ACL: Access Control List, 访问控制列表
- RBAC: Role Base Access Control, 基于角色的权限控制
- ABAC: Attribute Base Access Control, 基于属性的权限控制
每种方案都有自己的优缺点, 笔者未深入学习, 这里就不班门弄斧了
在笔者经历的大部分工作项目中, 使用最频繁的是第二个RBAC
所以本文后续所有内容是基于Spring Security 5的RBAC权限管理模型的实现
2 为什么是Spring Security 5
在众多权限管理方案中, 一定有部分设计思想或代码实现是共通的
Spring Security的出现为我们提供了多种解决方案
按照官网的说法, Spring Security是一种安全框架, 它可以让我们更便捷的定制自己应用的权限管理
那为什么选择最新的版本呢?
电子产品买新不买旧, 对于笔者而言, 开源项目也是一样的
笔者选择Spring Security 5的主要原因还包括Authorization Server相关仓库的废弃
3 实现步骤
想要集成Spring Security 5, 我们需要完成以下内容的处理:
- RBAC模型数据库设计
- 设计数据类
- 实现UserDetails
- 实现UserDetailsService
- Spring Security 5 配置
3.1 RBAC模型数据库设计
基于角色的权限控制, 顾名思义, 即通过为用户配置不同的角色, 每个角色又拥有不同的权限, 从而完成系统的权限管理
所以必然会涉及三个数据表: 用户表(t_user)/角色表(t_role)/权限表(t_permission)
这里的权限表又可以延申为菜单表, 二者在抽象上的意义是有重叠的
简单的系统到这里便可以运转了, 但当下大部分采用的是前后端分离的开发模式, 所以还需要再增加一个概念, 即接口表(t_api)
在用户概念上, 许多系统还会增加一个用户组, 笔者面对的更多是业务系统的开发, 于是将用户组的概念简化为了组织机构和部门, 但这部分对RBAC本身影响大大, 后续内容也不会涉及, 按照实际需求进行调整即可
最后总结一下, 其实权限的结构关系可以理解为: 用户->角色->权限->接口
用一张数据库关系图可以非常直观的进行说明:
未完待续…
本文转载自: 掘金