基于资源的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
如果文章帮助您解决了工作难题,您可以帮我点击屏幕上的任意广告,或者赞助少量费用来支持我的持续创作,谢谢~
