基于资源的RBAC设计思路

下面记录了基于资源视角的RBAC权限系统设计思路,直接从markdown贴上来了,作为备忘。

RBAC

用户

RBAC通常作为独立的服务存在,与登录认证系统是隔离的,因此RBAC服务不需要保存uid。

  • uid: 用户唯一性标识

权限

通用表结构,无需理解资源类型与细节结构。

  • permission_id: 权限唯一ID
  • permission_code:权限全局唯一标识(业务可读性)
  • resource_type: 资源类型
  • resource_id: 资源ID

唯一键:

  • (permission_code)
  • (resource_type, resource_id)

资源

不同的资源类型,需要的表结构不同,因此一类资源可以对应一张表。

以”项目-菜单-按钮”这类业务为例,其资源表结构如下:

  • resource_id: 资源ID
  • resource_type:资源类型(项目、菜单、按钮)
  • resource_parent_id: 父资源ID
  • 其他资源个性化信息

每条资源记录,需要在权限表建立对应的权限记录,用以约束对资源的访问。

用户-权限

最终用户可以访问哪些资源,是通过该表为用户授权实现的,而不是直接让用户与具体类型的资源产生关联。

  • uid: 用户ID
  • permission_id:权限ID

每个权限对应某个资源,可以通过”权限表”根据(resource_type,resource_id)进一步路由到对应”资源表”,获取资源详细信息。

角色

通常管理员优先给用户分配角色,而不是直接分配资源的访问权限给用户,这更利于简化权限管理。

角色可以预先关联若干权限。

  • role_id:角色ID
  • role_code:角色唯一标识

角色-权限

一个角色关联多个权限。

  • role_id: 角色ID
  • permission_id:权限ID

用户-角色

为用户赋予多种角色,从而拥有了角色关联的资源访问权限。

  • uid: 用户ID
  • role_id:角色ID

如果文章帮助您解决了工作难题,您可以帮我点击屏幕上的任意广告,或者赞助少量费用来支持我的持续创作,谢谢~