基于角色的访问控制（RBAC）模型实现报告
- 引言
在我原本开发的基于 Java 的外卖管理系统中，员工之间并没有精细化的权限控制，不同岗位的员工共享了相同的后台操作权限。为了解决这一问题，并实现系统管理员、店铺管理员与普通员工之间的差异化访问控制，我基于课程中学习的 RBAC（基于角色的访问控制）模型，对系统权限模块进行了设计与实现，从而显著提升了系统的安全性和可维护性。
- RBAC 模型简介
RBAC（Role-Based Access Control，基于角色的访问控制）是一种广泛应用于安全系统中的权限管理模型。该模型不再直接将权限分配给用户，而是通过角色这一中间层，将权限赋予角色，再将角色赋予用户，从而实现更具扩展性、可维护性与安全性的权限管理方式。
RBAC 的核心逻辑如下图所示：
图 1RBAC 权限控制关系示意图
在此模型中，用户通过所分配的角色来获取访问权限，而角色封装了一组特定的权限。
RBAC 模型包含以下基本元素：
- 用户（User）：系统的使用者；
- 角色（Role）：代表某一职责或岗位；
- 权限（Permission）：对某项资源操作的授权。
该结构简化了权限管理流程，有助于权限审计与策略执行。
- 角色与权限需求分析
|----------------|--------------|-----------------------------------------------------------------------------------------------------------------------------------|
| 角色名 | 描述 | 所需权限 |
| 店主（Owner） | 拥有全部权限的系统管理员 | employee:view, employee:add, dish:add, dish:update, dish:delete, order:list, order:detail, statistics:view, category:, setmeal: |
| 店铺管理员（Manager） | 协助管理店铺运营 | dish:add, dish:update, order:list, statistics:view, category:view, setmeal:view |
| 员工（Staff） | 处理日常订单与只读权限 | order:list, dish:view, category:view, setmeal:view |
- 数据库设计
为实现不同角色的权限映射，并避免硬编码，我设计了如下数据库结构支持多对多关系：
图 2数据库表结构设计示意图
用户登录后，系统通过 employee_role 表查询用户所拥有的所有角色，再通过 role_permission 表获取其对应的权限，并将其缓存至 JWT 或 ThreadLocal，供后续权限校验使用。该结构支持灵活扩展与权限解耦，增强了系统的适应性。
- 初始化数据
为实现 RBAC 模型，部署时系统初始化了以下数据：
角色表
|---------------|-----------------|
| Role Name | Description |
| Admin | 拥有全部权限的管理员 |
| Manager | 店铺管理员 |
| Staff | 普通员工 |
权限表
包括但不限于以下权限：
|---------------------|-----------------------------------------|
| Permission Code | |-----------------| | Description | |
| employee:view | 查看员工信息 |
| employee:add | 添加员工 |
| employee:update | |------| | 修改员工 | |
| ... | ... |
角色与权限映射
|----------|--------------------------|
| Role | Assigned Permissions |
| Admin | 全部权限 |
| Manager | 除员工管理外所有权限 |
| Staff | 查看订单、菜品、分类、套餐权限 |
员工与角色绑定
|-----------------------|-------------------|
| Employee Username | Assigned Role |
| admin | Admin |
| manager001 | Manager |
| staff001 | Staff |
- Java 实现部分
为实现基于角色的权限控制，系统后端引入以下关键组件：
EmployeeController
负责登录处理，并从业务层获取权限信息写入 JWT。
图 3 控制器中嵌入权限信息的流程
EmployeeService
根据员工 ID 查询其角色，并进一步获取权限列表。
图 4 角色与权限映射逻辑是 RBAC 实现的核心
PermissionAspect（AOP 权限切面）
在方法执行前判断当前用户是否拥有指定权限，否则抛出异常。
图 5通过注解 + AOP 实现运行时权限校验。
JwtUtils
负责权限信息的生成与解析。
图 6 登录成功后将权限名称列表写入 JWT
图 7 解析 JWT 并将权限缓存至 ThreadLocal
全局异常处理器
捕捉无权限访问异常，并返回统一格式的错误提示。
图 8权限异常提示与前端配合完成提示展示
- 功能演示
本系统成功实现了 RBAC 模块，并以系统管理员、店铺管理员、员工三类角色为例完成功能验证。
首先使用管理员账户登录，成功访问员工管理页面，具备添加与修改等权限。
随后使用店铺管理员账户登录，员工管理页面无法加载数据，抓包结果显示后端返回了"无权限"的提示信息，正是我们在全局异常处理器中设置的响应内容，验证了权限校验机制的生效。
- 问题与解决方案
问题 1：数据库结构设计问题
最初采用物理外键约束，但在员工与角色、权限等数据绑定后，对数据进行修改变得困难，最终改为使用逻辑外键，通过业务逻辑保障一致性，提高了灵活性。
问题 2：权限未正确加载
登录后虽然成功绑定角色，但权限未加载，原因是 MyBatis 动态 SQL 参数名不一致（如 id 与 roleIds），修正参数后问题解决。
问题 3：JWT 权限存储问题
最初将完整权限数据写入 JWT，导致 Token 过长，解析失败。最终改为仅存权限名列表，并通过拦截器与 AOP 配合进行校验。
- 总结
本次基于 RBAC 的权限控制模块成功实现了多角色的精细化访问控制，通过数据库设计、数据初始化、JWT 注入、AOP 拦截等技术手段，构建了完整的权限管理机制。
开发过程中经历了外键设计、Token 设计、动态 SQL 传参、前后端协同等一系列问题，均成功解决，进一步加深了我对 RBAC 模型、权限控制、拦截器与 AOP 的理解。
该模块显著提升了系统安全性与灵活性，为后续引入菜单权限、数据权限、可视化配置等功能奠定了坚实基础。