我有一个用 Keycloak 保护的网络应用程序。为了保持对服务的简短描述，我们将用户和文档作为服务中的实体。用户可以访问一个或多个文档，并且可以编辑或阅读文档。
目前我们有管理员、最终用户、开发人员等角色。然后我们在 Keycloak 之外保留一个数据库表，将文档映射到用户以及哪个用户对哪个文档具有什么访问级别。我们所有的最终用户在 Keycloak 中都有 EndUser 角色。每次最终用户尝试读取/编辑文档时，我们都必须在数据库表中进行查找以获得授权。
我们想将该表迁移到 Keycloak。据我了解，我基本上有两个选择：
创建很多角色，每个文档创建两个角色，名称如 doc_read_[DOCUMENT-ID] 和 doc_edit_[DOCUMENT-ID] 等。然后将正确的角色分配给正确的用户。这里的缺点是角色数量会增加很多。此外，附加到用户的角色数量将非常多。
为每个文档创建一个组，名称为文档 id。为读/写设置不同的子组，然后将用户添加到正确的组中。缺点是组的数量会非常多。此外，我将依赖对组名的授权，因此必须将组名列表映射到令牌。
我不想为每个用户添加带有文档 ID 的用户属性。使用这种方法，我无法获得文档的概览，也无法查看哪些用户可以访问给定的文档。
这里的最佳实践是什么？是否有其他解决方案可以解决此问题？这一定是很常见的设置。
答案 0 :(得分：2)
这只是我的看法。
据我所知，这两种解决方案都不理想，为每个文档添加一个角色是不自然的，而且粒度太细了。正如您已经提到的，这会导致角色过多，您可能不得不将它们添加到令牌中。
我个人将 Keycloak 仅用于身份验证部分，并在后端进行授权部分。我还会尝试以反映允许哪些用户角色操作它们的方式对文档进行分组。
或者，您可能会尝试使用 Keycloak 的授权功能来处理该用例，但我从未使用过它，因此关于此选项我无话可说。
答案 1 :(得分：0)
在我看来，您想要实现的目标与您的业务逻辑密切相关，我不建议依赖 keycloak 来实现。你的代币会不断增长，管理真的会是一场噩梦。
我认为拥有一个具有良好缓存来查找权限的服务没有问题，大部分数据不会随着时间的推移而发生太大变化。