基于 RBAC 的 Web 应用权限管理的思考

• 仅针对单一应用, 如果需要多应用的统一权限管理, 可能还需要加上「应用」这个层级的范围
• 以类似「白名单」的形式来计算权限, 保持的是一种累加的方式, 没有考虑权限互斥的情况, 也没有加入「黑名单」的设置
• 如果不需要特别针对某一个用户授权, 可以在角色绑定时, 只使用组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, 表明「当前(组内)用户」可以「在一定范围内」对资源「进行角色拥有的全部操作」
• 在绑定时, 需要注意数据权限的优先级问题

极简页面(部分)

• 如有错误, 请各位多多包含, 期待你的指教.
• 年前会基于此实现权限模块, 代码随后更新到 Github

• Microsoft Azure 的权限设计
• Kubernetes 的权限设计
• RBAC 说明

推荐阅读更多精彩内容

• 基于RBAC的权限设计与思考

  一、RBAC基础 0. 前言 最近刚参与设计完角色权限的第二版，趁着还有些印象，赶紧来总结下，省的以后忘记了。 1...

  阅读 2,333评论 0赞 24
• 2018-06-11

  mean to add the formatted="false" attribute?.[ 46% 47325/...

  阅读 1,143评论 0赞 3
• github地址，欢迎大家提交更新。

  github地址，欢迎大家提交更新。 express() express()用来创建一个Express的程序。ex...

  阅读 991评论 0赞 1
• express 4.x Api 中文版-最新中文详细解释

  Address:https://www.zybuluo.com/XiangZhou/note/208532 Exp...

  阅读 9,093评论 2赞 54
• RBAC 基于角色的权限访问控制

  在20世纪90年代期间，大量专家学者和研究单位对RBAC（Role-Based Access Control）的概...

  阅读 4,851评论 7赞 149