写在最前
- 仅针对单一应用, 如果需要多应用的统一权限管理, 可能还需要加上「应用」这个层级的范围
- 以类似「白名单」的形式来计算权限, 保持的是一种累加的方式, 没有考虑权限互斥的情况, 也没有加入「黑名单」的设置
- 如果不需要特别针对某一个用户授权, 可以在角色绑定时, 只使用组id
- 通过设置一定的规则, 通过初始化的方式, 可以实现应用权限的自省, 如下,
- 资源类型表: {'id': 1, 'name': '*', 'desc': 'ALL'}
- 资源操作表: {'id': 1, 'name': '*', 'desc': 'ALL'}
- 权限表: {'id': 1, 'res_kind_id': 1, 'res_verb_id': 1}
- 角色表: {'id': 1, 'name': 'Administrator', 'desc': 'Administrator'}
- 角色权限表: {'id': 1, 'role_id': 1, 'perm_id': 1}
- 用户表: {'id': 1, 'name': 'System'}
- 用户组表: {'id': 1, 'name': 'Administrator'}
- 组用户关联表: {'id': 1, 'group_id': 1, 'user_id': 1}
- 数据权限表: {'id': 1, 'desc': 'Administrator', 'res_kind': 1, 'res_attr': 1, 'operator': '', 'pattern': '', 'dup_op': '', 'priority': 1}
- 角色绑定表: {'id': 1, 'role_id': 1, 'kind': 'group', 'kind_id: 1', 'scope_id': 1}
数据库设计
- 所有的表默认包含 id（自增主键）
-
对于关联表, 外键的是通过业务逻辑来实现, 并非是物理上的外键关联（在建表时声明 ForeignKey）
authorization.png
资源类型 (ResourceKind)
- 定义当前系统存在的资源类型, 例如, 菜单/ 按钮/ 用户/ 角色 等
资源操作 (ResourceVerb)
- 定义可以对资源进行的操作, 例如, 查看/ 增加/ 删除/ 更新/ 授权 等
资源类型元信息 (ResourceMeta)
- 定义了某一资源类型所包含的属性信息, 包括类型/ 约束 等
具体的资源表 (ConcreteResource)
- 定义具体的资源表, 表名与 ResourceKind 相关, 字段信息来自 ResourceMeta
对于具体的、已知需求的应用来说, 以上的信息都是已知的, 类似于枚举, 可以通过配置文件的形式来替代
权限表 (Permission)
- 资源类型id + 资源操作id
角色表 (Role)
- 是一组权限的集合, 因此, 需要与权限进行绑定
角色权限表 (RolePermission)
- 角色id + 权限id, 定义角色可以操作哪些资源, 将权限与角色绑定在一起
- 权限与角色绑定在一起之后, 才算是完成一个角色完整的定义
数据权限 (DataScope)
- 定义数据的操作规则, 即在通过操作资源类型认证的情况下, 对于具体的资源是否可以应用此操作, 例如, 用户A查看非管后台类型的菜单, 这里的「非后台类型」就是数据权限, 即 菜单会有一个属性 kind（描述菜单类型）
- 所包含的字段
- desc: 范围描述
- res_kind: 资源类型id
- res_attr: 资源类型的具体属性
- operator: 操作符, 例如, =, != 等, 这里可以根据实际需求来设置
- pattern: 需要匹配的信息, 例如, 'not_admin'
- dup_op: 当同一个属性有多种不同的数据权限时, 如何连接此条权限, 例如, and, or 等
- priority: 优先级, 当用户拥有 对同一个资源的不同操作时, 会按照优先级的大小, 通过 dup_op 进行条件拼接
- 数据权限在使用时的形式, <res_kind>.<res_attr> <:operator> <pattern>, 例如, menu.kind = 'not_admin'
- 特别的,
- 针对全部资源类型, 可以设定, res_kind = '*'
- 类推, 针对整个资源类型, 可以设定 res_attr = '*'
用户表 (User)
- 保存用户信息
用户组 (Group)
- 组信息
组用户关联表 (GroupUser)
- 组id + 用户id, 将用户与组绑定在一起
角色绑定表 (RoleBind)
- 角色id + 组id/用户id + 数据权限id, 表明「当前(组内)用户」可以「在一定范围内」对资源「进行角色拥有的全部操作」
- 在绑定时, 需要注意数据权限的优先级问题
极简页面(部分)
simple_ui.png
写在最后
- 如有错误, 请各位多多包含, 期待你的指教.
- 年前会基于此实现权限模块, 代码随后更新到 Github
参考资料
- Microsoft Azure 的权限设计
- Kubernetes 的权限设计
- RBAC 说明
