Spring Security中角色和GrantedAuthority之间的区别

一尘不染

Spring Security中角色和GrantedAuthority之间的区别

spring

Spring Security中有一些概念和实现，例如GrantedAuthority用于获得授权来授权/控制访问权限的接口。

我希望对允许的操作（例如createSubUsers或deleteAccounts）进行允许，这些操作将允许管理员（具有role ROLE_ADMIN）使用。

在网上看到的教程/演示让我感到困惑。我尝试将我阅读的内容联系起来，但我认为我们可以将两者互换。

我看到正在hasRole消耗GrantedAuthority字符串吗？我肯定在理解上做错了。Spring Security中的这些概念是什么？

如何将用户角色与角色的权限分开存储？

我还查看org.springframework.security.core.userdetails.UserDetails了身份验证提供程序引用的DAO中使用的接口，该接口消耗了User（请注意最后的GrantedAuthority）：

public User(String username, 
            String password, 
            boolean enabled, 
            boolean accountNonExpired,
            boolean credentialsNonExpired, 
            boolean accountNonLocked, 
            Collection<? extends GrantedAuthority> authorities)

还是有其他方法可以区分其他两个？还是不受支持，我们必须自己做？

阅读 5439

2020-04-12

共1个答案

一尘不染

将GrantedAuthority视为“权限”或“权利”。这些“权限”（通常）用字符串表示（使用getAuthority()方法）。这些字符串使你可以标识权限，并让你的选民决定他们是否授予对某些内容的访问权限。

你可以通过将用户置于安全上下文中来为其授予不同的GrantedAuthority（权限）。通常，你可以通过实现自己的UserDetailsService来实现此目的，该服务返回一个UserDetails实现，该实现返回所需的GrantedAuthorities。

角色（在许多示例中使用过）只是“权限”，使用命名约定表示角色是以prefix开头的GrantedAuthority ROLE_。没什么了一个角色就是一个GrantedAuthority-一个“权限”-一个“权利”。你会在Spring Security中看到很多地方，带有ROLE_前缀的角色是专门处理的，例如在RoleVoter中，ROLE_前缀被用作默认值。这样，你就可以提供角色名称而无需添加ROLE_前缀。在Spring安全4之前，这种对“角色”的特殊处理并未得到非常一致的遵循，并且权限和角色通常被视为相同（例如hasAuthority()hasRole()）。使用Spring Security 4，角色的处理更加一致，处理“角色”的代码（如RoleVoter，hasRole表达式等）总是ROLE_为你添加前缀。所以hasAuthority('ROLE_ADMIN')指一样hasRole('ADMIN')，因为ROLE_前缀被自动添加。有关更多信息，请参见Spring Security 3到4 迁移指南。

但是，角色仍然只是带有特殊ROLE_前缀的授权机构。因此在Spring安全性3 @PreAuthorize("hasRole('ROLE_XYZ')")中与相同@PreAuthorize("hasAuthority('ROLE_XYZ')")，在Spring安全性4 @PreAuthorize("hasRole('XYZ')")中与相同@PreAuthorize("hasAuthority('ROLE_XYZ')")。

关于你的用例：

用户具有角色，角色可以执行某些操作。

你可能最终会GrantedAuthorities获得用户所属的角色以及角色可以执行的操作。在GrantedAuthorities对角色有前缀ROLE_和操作都有前缀OP_。一个例子为业务主管部门可能是OP_DELETE_ACCOUNT，OP_CREATE_USER，OP_RUN_BATCH_JOB等角色可以是ROLE_ADMIN，ROLE_USER，ROLE_OWNER等。

你最终可能会GrantedAuthority像下面的（伪代码）示例中那样使你的实体实现：

@Entity
class Role implements GrantedAuthority {
    @Id
    private String id;

    @ManyToMany
    private final List<Operation> allowedOperations = new ArrayList<>();

    @Override
    public String getAuthority() {
        return id;
    }

    public Collection<GrantedAuthority> getAllowedOperations() {
        return allowedOperations;
    }
}

@Entity
class User {
    @Id
    private String id;

    @ManyToMany
    private final List<Role> roles = new ArrayList<>();

    public Collection<Role> getRoles() {
        return roles;
    }
}

@Entity
class Operation implements GrantedAuthority {
    @Id
    private String id;

    @Override
    public String getAuthority() {
        return id;
    }
}

你在数据库中创建的角色和操作的ID将是GrantedAuthority表示形式，例如ROLE_ADMIN，OP_DELETE_ACCOUNT等等。对用户进行身份验证时，请确保从UserDetails.getAuthorities（）返回了其所有角色的所有GrantedAuthority和相应的操作方法。

例如：ID为admin角色ROLE_ADMIN有操作OP_DELETE_ACCOUNT，OP_READ_ACCOUNT，OP_RUN_BATCH_JOB分配给它。ID为的用户角色具有ROLE_USER操作OP_READ_ACCOUNT。

如果造成安全上下文管理员日志将有GrantedAuthorities： ， ROLE_ADMIN，，OP_DELETE_ACCOUNTOP_READ_ACCOUNTOP_RUN_BATCH_JOB

如果一个用户登录它，它就会有： ROLE_USER，OP_READ_ACCOUNT

UserDetailsService将注意收集所有角色以及这些角色的所有操作，并通过返回的UserDetails实例中的方法getAuthorities（）使它们可用。

2020-04-12