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

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

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

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

角色（在许多示例中使用过）只是“权限”，使用命名约定表示角色是以prefix开头的

GrantedAuthority ROLE_

。没什么了 一个角色就是一个

GrantedAuthority

-一个“权限”-一个“权利”。你会在Spring Security中看到很多地方，带有

ROLE_

前缀的角色是专门处理的，例如在

RoleVote

r中，

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

像下面的（伪代码）示例中那样使你的实体实现：

@Entityclass 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;    }}@Entityclass User {    @Id    private String id;    @ManyToMany    private final List<Role> roles = new ArrayList<>();    public Collection<Role> getRoles() {        return roles;    }}@Entityclass 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

UserDetailsS​​ervice

将注意收集所有角色以及这些角色的所有 *** 作，并通过返回的UserDetails实例中的方法

getAuthorities（

）使它们可用。