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

Scalable architecture for multi-tenant auth solution

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

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

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

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

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

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

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

例如

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

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

我们一直在为此评估 Authorization API (based on UMA)，但目前不适合，因为 KeyCloak 上有许多未解决的问题需要解决。

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

如果您仍想继续使用 Keycloak 并坚持这些标准，我建议您查看 Keycloak Authorization Services。

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