下面记录了基于资源视角的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