我正在使用Spring Security ACL。当我保存对象时，我还创建了一个新的ACE（访问控制条目）。我正在使用这种方法：
acl.insertAce(acl.getEntries().size(), BasePermission.CREATE, recipient, true);
我想知道如果我一次调用此方法获得所有权限，所有者（添加它的经过身份验证的用户）应该具有相同的权限，我是否认为是正确的？
示例：
如果添加条目的用户也应具有READ访问权限，我会再次调用此文件：
acl.insertAce(acl.getEntries().size(), BasePermission.READ, recipient, true);
等等？这是应该正确使用的方式吗？
在ACL中只拥有权限和主体，或者只是主体是正常的。我的意思是，您是在hasRole('ROLE_ADMIN')中混合hasPermission(...)和@PreAuthorize还是在ACL中同时拥有主体和权限，因此您只能使用hasPermission(...)
答案 0 :(得分：2)
默认情况下，当Spring Security ACL评估权限时，它会考虑更高的权限。例如，如果您具有CREATE（2）权限，则自动表示您具有READ（1）权限。出于某种原因，我很难找到特定的查询，这是他们的默认策略之一。因此，在给出CREATE权限后，您不必授予READ权限。
就组合角色和权限检查而言，完全正常。例如，在我的应用程序系统中，管理员（ROLE_ADMIN）是可以执行任何操作的超级用户，例如更新其他用户的数据，以下是我如何检查当前用户是否可以更新实体，其中#entity是您要更新的实际对象：
@PreAuthorize("hasPermission(#entity, 'ADMINISTRATION') or hasRole('ROLE_ADMIN')")
如果您想要更精细的权限，可以使用安全组。例如，在我的应用程序中，用户可以宣传他们教授的不同课程，可以在全球范围内教授课程（user@example.com可以在任何地方教授此课程），在健身房层面（任何健身房ID 123的教练可以教授本课程）或者健身教练水平（user@example.com可以在健身房ID 123教授这门课程）。为了支持这样的事情，你需要有3个级别的权限：
Global：user@example.com - ＆gt;这是一个SidPrincipal
健身房：GYM_123_TRAINERS - ＆gt;这是一个GrantedAuthoritySid
健身教练：GYM_123_TRAINERS-user@example.com - ＆gt;这是一个GrantedAuthoritySid
当用户登录时，我会遍历他所教授的所有健身房，并添加GYM_ID_TRAINERS角色以确定他是健身教练组的一部分，并使用GYM_ID_TRAINERS-用户名角色将他识别为该健身房。
答案 1 :(得分：0)
这个问题背后似乎有许多假设/问题需要解开。我将解释我认为潜在的问题，并添加一些问题以澄清一些可能存在的假设；希望我已经正确理解了这个问题：
CREATE 是否比 READ“更强”？hasPermission 与 hasRole 混合使用吗？让我一一回答这些问题。
首先，当前经过身份验证的用户不一定与我们为其授予权限的 SID 相同。例如，Alice 可能是管理员，他登录并为 SID bob 调用此方法：
acl.insertAce(acl.getEntries().size(), BasePermission.CREATE, bob, true);
在这种情况下，bob 可以是主体，即另一个用户，也可以是权限，即某个角色。为简单起见，我们假设 bob 仅指代用户 Bob，即委托人。
让我们继续我们的例子，假设 Alice 想要授予 Bob 权限。 Alice 需要具备什么权限才能授予 Bob CREATE 权限？在 OOTB Spring ACL 中，我们假设您在 ACL 配置中定义了一个授权策略 Bean，如下所示：
@Bean
fun aclAuthorizationStrategy(): AclAuthorizationStrategy {
return AclAuthorizationStrategyImpl(
SimpleGrantedAuthority("ADMIN")
)
}
在这种情况下，我们所说的是具有“ADMIN”角色的任何人都有权对 ACLS 执行任何管理操作，例如授予另一个用户 CREATE 对某些 ACL 的权限。请注意，在这种情况下，拥有“ADMIN”角色赋予管理员访问所有 ACL 的权限。因此，Alice 可能具有“ADMIN”角色，并且通过上述配置，这意味着她可以将 CREATE 授予 bob。
但是 Alice 可以通过另一种方式授予权限。她可能对与 ACL 本身相关的对象具有管理访问权限。例如，对象可能是某个 BankAccount。在 Spring ACL OOTB 中，BasePermission 实例 ADMINISTRATION 控制是否允许某人对某个对象执行管理操作。请注意，在这种情况下，管理权限仅适用于单个对象，而不是角色的系统范围。
CREATE 是否比 READ“更强”？不，Spring 中默认没有权限层次结构。因此，在撰写此答案时，this answer 是不正确的。
假设你像这样保护一个函数：
@PreAuthorize("hasPermission(#entity, 'WRITE')")
您的意思是“仅允许对此实体拥有 WRITE 权限的用户访问此功能”。在 OOTB Spring 中，这意味着您需要明确授予用户 WRITE 权限，以便他们能够访问该功能。授予任何其他权限，即使是 ADMINISTRATION 也不会解锁对该函数的访问，因为 Spring ACL 只会准确检查 WRITE 权限。注意：这只是 Spring OOTB 的行为。您始终可以覆盖权限评估器以执行您喜欢的任何操作。因此，如果您想要分层权限，您当然可以通过自定义权限评估器来实现，例如 done here。
hasPermission中混合hasRole和@PreAuthorize吗？正如this answer 正确指出的那样，答案是肯定的。事实上，您可以将任何您喜欢的有效 SpEL 表达式放入 @PreAuthorize 注释中。它甚至完全不必与 Spring ACL 相关。