前言:
RBAC是Role-Based Access Control的缩写, 它几乎成为权限系统的数据模型的选择标配.
之前写个两篇关于权限系统的文章, 主要涉及如何在应用中实现权限控制, 对权限系统本身的数据模型未着水墨. 权限系统的设计到现在为止, 非常的成熟, 而且网上的资料大而全. 比如这篇博文: 权限系统与RBAC模型概述, 其基本就涵盖了各类RBAC的权限数据模型的设计, 可根据小/中/大的业务场景进行定制.
本文结合自己的业务场景, 介绍一个小型的后台管理系统的权限系统(RBAC)的数据模型, 权做笔记, ^_^.
相关系列文章:
1. springmvc简单集成shiro
2. 类Shiro权限校验框架的设计和实现
设计目标:
最简化RBAC的数据模型, 同时为了给系统添加一定的灵活度, 即可以单独给用户赋予某个特定权限.
这边把权限定义为:
permission(权限) = resource(资源) + action(动作)
对于资源(resource), 不在细分为页面(page)级别, 甚至到按钮(menu)级别. 资源更像一个具体的业务/功能的标记.
对于动作(action), 可以简单分为read/write/update/delete.
这样权限(permission)就很容易定义和理解, 比如功能: 查看投诉, 其对应permission为: complaint:read.
role和user都相对独立, 即role没有继承和层次关系, 用户不再引入组group.
这样的话, 将大大减少权限的设计, 避免在中小型业务后端, 进行过度设计, 导致工作量膨胀且没明显增量收益.
为了系统一定的灵活度, 在单独引入user到permission的直接映射表, 用于扩展.
数据模型:
对了小型的后台管理系统, 用户不多, 表可以采用单库单表, 总之尽量简单, 这边的表都保留id字段(主键自增)作为约定.
作为最基础的RBAC表设计:
为了增加灵活性, 单独添加的用户到权限的双向映射表.
事实上, 如果业务规模真的不大, 且权限的粒度较粗, 完全退化为了用户/权限表模型, 也是可以完全满足需求的, 而且实现更快.
这边结合了两种, 算是一个小复合模式.
后记:
RBAC的权限确实很成熟, 不过还是那句老话, 纸上得来终觉浅, 绝知此事要躬行.
本文权做个人笔记了.