基于不同Keycloak服务器的身份认证与授权方案可行性问询

方案可行性结论 #

这个架构完全可行，Keycloak的OIDC联邦信任机制、令牌校验能力以及角色映射功能可以完美支撑「多认证Keycloak+单授权Keycloak」的模式，满足OrgA/OrgB用户体系独立、统一授权校验的需求。

具体实施步骤 #

1. 配置授权专用Keycloak（无用户存储，仅做RBAC校验） #

• 创建API网关专用客户端：
  • 为API网关创建客户端，开启Service Accounts Enabled，生成client_id和client_secret，用于网关调用授权校验接口。
  • 开启Authorization Enabled，后续可基于此配置资源、权限策略（如果需要细粒度授权）。
• 定义全局统一角色集：
  • 在授权Keycloak的Realm下创建所有API资源对应的角色（如api:order:read、api:user:write），这些角色是授权校验的唯一依据。
• 禁用用户管理相关功能：
  • 关闭Realm的用户注册、邀请功能，避免误创建用户；仅保留角色、客户端、身份提供者的配置权限。

2. 配置OrgA/OrgB的认证专用Keycloak #

• 同步授权Keycloak的角色：
  • 在各自的Realm下创建与授权Keycloak完全同名的角色，或者通过角色映射器将本地角色转换为授权Keycloak认可的角色名称。
  • 将这些角色分配给对应的用户或用户组。
• 配置令牌角色注入：
  • 在面向用户的客户端（比如前端登录客户端）中添加User Realm Role映射器，将角色注入到JWT的realm_access.roles字段；如果需要自定义字段，可添加Script Mapper将角色写入指定字段（如auth_roles）。
• 配置令牌信任规则：
  • 在客户端的Valid Audiences中添加授权Keycloak的网关客户端ID，确保令牌的aud字段包含该值，让授权Keycloak认可令牌的受众。
• 开放OIDC发现端点：
  • 确保认证Keycloak的/.well-known/openid-configuration端点可被授权Keycloak访问，用于自动获取公钥验证令牌签名。

3. 改造API网关的授权校验逻辑 #

• 替换令牌校验目标：
  • 将原有的单Keycloak校验请求，改为发送到授权Keycloak的/protocol/openid-connect/token/introspect接口，传入用户令牌和网关的client_id/client_secret。
• 扩展授权校验逻辑（可选）：
  • 如果需要细粒度资源授权，调用授权Keycloak的/authz/authorize接口，传入令牌、资源ID、操作类型，由授权Keycloak根据预设策略返回授权结果。
• 处理校验结果：
  • 若introspect接口返回active: true，且令牌中的角色包含目标资源所需角色，则允许访问；否则拒绝请求。

4. 关键注意事项 #

• 角色名称一致性：认证Keycloak注入令牌的角色必须与授权Keycloak定义的角色完全匹配，否则授权校验会失败。可通过映射器解决命名差异问题。
• 签名信任机制：授权Keycloak需通过OIDC发现端点自动拉取认证Keycloak的公钥，避免手动配置公钥带来的维护成本；若网络隔离，可手动导入认证Keycloak的公钥到授权Keycloak的信任列表。
• 令牌有效期：统一配置所有Keycloak实例的令牌有效期，避免因令牌过期时间不一致导致的校验问题。
• 日志与监控：为所有Keycloak实例和API网关配置日志监控，跟踪令牌生成、校验的全流程，便于排查问题。

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