应用错误收集

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

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

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

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

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

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

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

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

E.g。

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

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

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

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