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

【问题标题】：Scalable architecture for multi-tenant auth solution多租户身份验证解决方案的可扩展架构
【发布时间】：2019-02-15 16:29:55
【问题描述】：

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

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

第一种方法动态客户注册

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

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

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

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

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

例如

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

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

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

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

【问题讨论】：

很棒的总结和非常有趣的问题，您找到解决方案了吗？我认为第二种方法可以很好地扩展，因为这个策略可以在运行时生成。我认为仅将所有 URN 添加到 JWT 并不明智。假设用户是 10 多个租户的一部分，很快就会达到限制。也许每个请求只在 JWT 中存储一个租户的详细信息？编辑：上下文
通常这两种方法都不能很好地解决这个问题。这不应该用 OAuth 来解决，而应该用服务器端 ACL 来解决。我建议您查看我的博客文章，了解我们使用的解决方案：blog.verygoodsecurity.com/posts/…

【解决方案1】：

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

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

【讨论】：