这更多的是一个早期阶段的问题，围绕着在Key斗篷中为用户创建的资源建模权限/角色的惯用方法。对于这个用例，我不确定是否应该只使用Key斗篷进行身份管理，而将访问管理留给应用程序。
建议的用例：在应用程序中，资源属于一家公司，一家公司可以有多个用户。有些用户是管理员用户，负责为其他用户设置角色/权限。这些权限可以授予全局访问权限(例如用户可以查看所有文件(或资源特定访问权限(如用户可以查看/修改营销文件夹中的文件(。
一个更具体的例子是AWS IAM。多个用户可以在一个AWS帐户上，但访问可以在不同级别进行控制。例如，可能会设置一个授予S3读取权限的角色，而另一个角色可能对市场存储桶具有S3删除权限。
由于这些资源/角色是由用户创建和管理的，我想我的应用程序需要提供自己的UI，然后使用RESTneneneba API与Keycapture通信。因为这些都是用户生成的，而且可能有很多公司在使用该应用程序，所以我可以预见大量与资源相关的数据将被持久化在Keycloft中。
我不确定这是否是一个好主意——我想我需要经常与Key斗篷服务器通信，以验证给定用户是否可以访问他们试图请求/修改的资源。Keycloft似乎更适合不绑定到特定用户创建的资源的作用域/权限？如果这是一个标准用例，那么有没有关于这种方法的文档(我什么都找不到(？
Key斗篷能够非常顺利地管理用户的角色，您可以在Java代码中使用以下注释：
@Secured("ROLE_ADMIN")
或
@RolesAllowed({"ROLE_USER", "ROLE_ADMIN"})
在控制器内部，连同HTTP方法的映射或在像这样的HTML代码内部
sec:authorize="hasRole('ADMIN')"
这意味着您可以管理查看/修改营销文件夹中文件的访问权限。要进一步提高用户访问级别，您可以使用令牌授权；请阅读例如这篇文章。