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

Question

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

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

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

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

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

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

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

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

EG

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

我觉得第一种方法更标准，但要求我们在系统中增加更多的复杂性，因为我们必须处理注册客户端并指导用户每次想要授予客户端服务器访问权限时通过身份验证委派流程拥有。第二种方法在技术上很简单，但标准较少。

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

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

Answer 1

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

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