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