用于多租户身份验证解决方案的可扩展架构

Question

我们正在评估用于设置KeyCloak 的两种不同架构，以允许用户向我们系统内的其他用户和第三方授予对租户的访问权限。

我正在寻找有关这些的有经验的反馈，以尝试节省一些实验时间。

第一种方法动态客户端注册

在这种方法中，我们将有几个静态服务（资源服务器）来协调访问，然后每个租户通过动态注册的客户端表示。

然后，我们将拥有一组静态角色（权限），当用户和客户端被授予访问权限时，它们会在用户和客户端之间分配。

然后固定角色的总范围。这里的扩散是在用户和客户端或资源服务器和客户端之间。

在这种方法中，我们正在考虑为系统中的每个租户动态生成角色（权限）。我们正在考虑镜像 AWS 的 URN 样式，以便权限看起来像 ssl_certificate_key

它们遵循一般结构 urn:service:tenant:permission

例如

这非常简单和强大，但随着我们将用户或服务连接到越来越多的租户，我们有可能使 JWT 的规模激增。

我觉得第一种方法更标准，但需要我们向系统添加更多的复杂性，因为我们必须处理注册客户端并引导用户完成身份验证委托流程，每次他们想要授予对客户端的服务器访问权限时自己的。第二种方法在技术上非常简单，但不太符合标准。

我们一直在为此评估授权 API（基于UMA），但目前不适合，因为 KeyCloak 上有许多未解决的问题需要解决。

人们在现实世界中倾向于做什么来解决这个问题？我们的系统拥有无限数量的租户，但实际上每个用户最多只能与几十个相关联。第三方应用程序（都是动态客户端）可能会与成百上千的其他客户端相关联。

Answer 1

如果您仍然想继续使用 Keycloak 并遵守这些标准，我建议您查看 Keycloak授权服务。

但是，另一个好的解决方案是https://www.openpolicyagent.org/，您可以在其中为每个租户指定策略。它不是 OAuth 2.0/OpenID Connect 的一部分，但它可以很好地跨多个服务进行扩展，因为它可以部署为 sidecar，但您需要用它构建一些权限存储服务。