基于Keycloak的多租户层级RBAC建模与权限控制实现咨询

层级关系最优建模方案 #

直接基于Keycloak原生的组（Group）层级能力搭建基础组织架构，天然支持权限继承规则，不需要额外二次开发：

• 第一层（Organization层级）：创建顶级租户组，命名规则统一为org:<组织唯一ID>，每个企业租户对应一个顶级组，组织级角色（如org:admin、org:viewer）直接挂载到该组下。
• 第二层（Group层级）：在每个Organization顶级组下创建子组，命名规则统一为org:<组织ID>:group:<分组唯一ID>，每个业务分组对应一个二级子组，分组级角色（如group:admin、group:viewer）挂载到该二级组下。
• 第三层（Apps层级）：在每个Group二级子组下创建孙组，命名规则统一为org:<组织ID>:group:<分组ID>:app:<应用唯一ID>，每个应用对应一个三级孙组，应用级角色（如app:admin、app:viewer）挂载到该三级组下。

权限继承规则的实现完全复用Keycloak的组角色继承能力：

• 高层级权限向下继承：给用户分配Organization顶级组的org:admin角色时，开启组角色的「向下继承」开关，Keycloak会自动将该角色的权限同步到该组织下所有二级分组、三级应用的资源范围，无需额外配置即可实现组织管理员天然拥有全下属资源的管理权限。
• 同层级权限叠加生效：如果用户已经拥有某个Group的group:viewer权限，可直接给该用户分配对应Group下某个App的app:admin角色，Keycloak默认权限叠加，不会出现低权限覆盖高权限的情况。

资源与权限绑定配置 #

搭配Keycloak的客户端授权能力实现细粒度权限控制：

• 每个App对应Keycloak内的一个独立Client，开启该Client的Authorization Enabled开关。
• 将App内的可操作资源、操作类型定义为该Client下的Resource和Scope，比如资源order对应增删改查四个Scope：create、delete、update、view。
• 给不同层级的角色绑定对应资源的Scope权限：比如org:admin绑定所属组织下所有App Client的全部资源Scope，group:viewer绑定对应分组下所有App Client的只读类Scope，app:admin绑定单个App Client的全部Scope。

获取用户全量权限列表的实现方式 #

有两种常用实现路径可拿到用户所有可访问权限及对应授权实体：

1. 令牌侧直接获取：在对应Client的Token Claim Names配置中，将用户所属组、分配角色、授权资源Scope全部加入ID Token/Access Token的自定义Claim，调用/realms/<领域名>/protocol/openid-connect/userinfo接口即可直接拿到结构化的全量权限数据。
2. Admin API查询：调用Keycloak管理接口GET /admin/realms/<领域名>/users/<用户ID>/permissions可直接拉取用户的全量授权数据；也可以先查询用户所属的所有组（包含继承的父组），再关联查询所有组绑定的角色、角色对应的资源权限，自行整理出用户所有可访问权限及对应的授权实体（组织/分组/应用）。

注意事项 #

• 不要使用Realm级角色做层级权限管控，Realm级角色默认全局生效，无法实现租户隔离。
• 组、角色命名建议加统一前缀，既可以避免不同租户的资源名冲突，也方便后续权限过滤时快速匹配层级关系。
• 高并发场景下建议在应用侧自行实现基于Token内组、角色信息的权限拦截，不需要完全依赖Keycloak的策略校验，性能会更高。

内容的提问来源于stack exchange，提问作者basu76