【问题标题】:Keycloak Authorization - best practice roles vs groupsKeycloak 授权 - 最佳实践角色与组
【发布时间】:2021-05-26 23:20:41
【问题描述】:

我有一个使用 Keycloak 保护的 Web 应用程序。为了使服务的描述简短,我们将用户和文档作为服务中的实体。用户可以访问一个或多个文档,并且可以编辑或阅读文档。

目前我们拥有诸如管理员、最终用户、开发人员等角色。然后,我们在 Keycloak 之外保留一个数据库表,用于将文档映射到用户以及哪些用户对哪些文档具有什么访问级别。我们所有的最终用户在 Keycloak 中都有 EndUser 角色。每次最终用户尝试读取/编辑文档时,我们都必须在数据库表中进行查找以进行授权。

我们想将该表迁移到 Keycloak。据我了解,我基本上有两种选择:

  • 创建很多角色,每个文档两个,名称为doc_read_[DOCUMENT-ID]doc_edit_[DOCUMENT-ID]等。然后将正确的角色分配给正确的用户。这里的缺点是角色的数量会增加很多。此外,附加到用户的角色数量会非常多。

  • 为每个文档创建一个组,名称为文档 ID。有不同的读/写子组,然后将用户添加到正确的组中。缺点是组的数量会非常大。另外,我将在组名上依赖授权,因此组名列表必须映射到令牌。

我不想为每个用户添加带有文档 ID 的用户属性。使用这种方法,我无法获得文档的概览,也无法查看哪些用户可以访问给定的文档。

这里的最佳做法是什么?有没有其他解决方案可以解决这个问题?这一定是很常见的设置。

【问题讨论】:

    标签: security authorization keycloak roles usergroups


    【解决方案1】:

    在我看来,您想要实现的目标与您的业务逻辑密切相关,我不建议您依赖 keycloak 来实现。你的代币会不断增长,而管理真的是一场噩梦。

    我认为拥有具有良好缓存以查找权限的服务没有问题,大部分数据不会随着时间的推移而发生太大变化。

    【讨论】:

      【解决方案2】:

      这只是我的意见。

      据我了解,这两种解决方案都不是最理想的,添加角色 per 文档是不自然的,而且粒度太细。正如您已经提到的那样,这会导致过多的角色,您可能必须将它们添加到令牌中。

      我个人将 Keycloak 仅用于身份验证部分并在后端执行授权部分。我还会尝试以反映允许哪些用户角色操作它们的方式对文档进行分组。

      或者,您也可以尝试使用 Keycloak 的授权功能来处理该用例,但我从未使用过它,因此关于此选项我无话可说。

      【讨论】:

        猜你喜欢
        • 2017-02-04
        • 2016-11-02
        • 2011-08-06
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2021-09-26
        • 2021-07-13
        • 2015-09-06
        相关资源
        最近更新 更多