Spring Security中Role和GrantedAuthority的区别 [英] Difference between Role and GrantedAuthority in Spring Security

问题描述

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

There are concepts and implementations in Spring Security, such as the GrantedAuthority interface to get an authority to authorize/control an access.

我希望这是允许的操作，例如 createSubUsers 或 deleteAccounts ，我允许这样做 admin （角色 ROLE_ADMIN ）。

I would like that to permissible operations, such as createSubUsers, or deleteAccounts, which I would allow to an admin (with role ROLE_ADMIN).

我对网上看到的教程/演示感到困惑。我尝试连接我读的内容，但我认为我们可以互换地对待这两个。

I am getting confused as the tutorials/demos I see online. I try to connect what I read, but I think we treat the two interchangeably.

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

I see hasRole consuming a GrantedAuthority string? I most definitely am doing it wrong in understanding. What are these conceptually in Spring Security?

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

How do I store the role of a user, separate from the authorities for that role?

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

I'm also looking at the org.springframework.security.core.userdetails.UserDetails interface which is used in the authentication-provider referenced DAO, which consumes a User (note last GrantedAuthority):

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

或者还有其他方法来区分其他两个吗？或者它是否不受支持我们必须自己制作？

Or is there any other way to differentiate the other two? Or is it not supported and we have to make our own?

推荐答案

将GrantedAuthority视为权限或对。那些权限（通常）表示为字符串（使用 getAuthority（）方法）。这些字符串可让您识别权限并让您的选民决定是否允许访问某些内容。

Think of a GrantedAuthority as being a "permission" or a "right". Those "permissions" are (normally) expressed as strings (with the getAuthority() method). Those strings let you identify the permissions and let your voters decide if they grant access to something.

您可以通过将其置于安全性中来向用户授予不同的GrantedAuthority（权限）上下文。您通常通过实现自己的UserDetailsS​​ervice来执行此操作，该UserDetailsS​​ervice返回返回所需GrantedAuthorities的UserDetails实现。

You can grant different GrantedAuthoritys (permissions) to users by putting them into the security context. You normally do that by implementing your own UserDetailsService that returns a UserDetails implementation that returns the needed GrantedAuthorities.

角色（在许多示例中使用它们）只是权限使用命名约定，该约定表明角色是以前缀 ROLE _ 开头的GrantedAuthority。没有别的了。角色只是一个GrantedAuthority - 一个权限 - 一个权利。你会在spring security中看到很多地方，其中 ROLE _ 前缀的角色是专门处理的，例如：在RoleVoter中， ROLE _ 前缀用作默认值。这允许您提供不具有 ROLE _ 前缀的角色名称。在Spring security 4之前，对角色的这种特殊处理并没有得到非常一致的遵守，权限和角色通常被视为相同（正如您在 hasAuthority（）的实现中所看到的那样方法expression / SecurityExpressionRoot.java> SecurityExpressionRoot - 只需调用 hasRole（））。使用Spring Security 4，角色处理更加一致，代码处理角色（如 RoleVoter ， hasRole 表达式等）总是为你添加 ROLE _ 前缀。所以 hasAuthority（'ROLE_ADMIN'）表示与 hasRole（'ADMIN'）相同，因为 ROLE _ 前缀自动添加。请参阅spring security 3到4 迁移指南以获取更多信息。

Roles (as they are used in many examples) are just "permissions" with a naming convention that says that a role is a GrantedAuthority that starts with the prefix ROLE_. There's nothing more. A role is just a GrantedAuthority - a "permission" - a "right". You see a lot of places in spring security where the role with its ROLE_ prefix is handled specially as e.g. in the RoleVoter, where the ROLE_ prefix is used as a default. This allows you to provide the role names withtout the ROLE_ prefix. Prior to Spring security 4, this special handling of "roles" has not been followed very consistently and authorities and roles were often treated the same (as you e.g. can see in the implementation of the hasAuthority() method in SecurityExpressionRoot - which simply calls hasRole()). With Spring Security 4, the treatment of roles is more consistent and code that deals with "roles" (like the RoleVoter, the hasRole expression etc.) always adds the ROLE_ prefix for you. So hasAuthority('ROLE_ADMIN') means the the same as hasRole('ADMIN') because the ROLE_ prefix gets added automatically. See the spring security 3 to 4 migration guide for futher information.

但仍然：角色只是一个具有特殊<$ c $的权限c> ROLE _ 前缀。所以在Spring安全3中 @PreAuthorize（hasRole（'ROLE_XYZ'））与 @PreAuthorize（hasAuthority（'ROLE_XYZ'）相同）并在Spring安全4中 @PreAuthorize（hasRole（'XYZ'））与相同@ PreAuthorize（hasAuthority（'ROLE_XYZ'））。

But still: a role is just an authority with a special ROLE_ prefix. So in Spring security 3 @PreAuthorize("hasRole('ROLE_XYZ')") is the same as @PreAuthorize("hasAuthority('ROLE_XYZ')") and in Spring security 4 @PreAuthorize("hasRole('XYZ')") is the same as @PreAuthorize("hasAuthority('ROLE_XYZ')").

关于您的使用案例：

用户拥有角色和角色可以执行某些操作。

Users have roles and roles can perform certain operations.

你最终可能会进入 GrantedAuthorities 用于用户所属的角色以及角色可以执行的操作。角色的 GrantedAuthorities 的前缀为 ROLE _ ，操作的前缀为 OP _ 。操作权限的示例可以是 OP_DELETE_ACCOUNT ， OP_CREATE_USER ， OP_RUN_BATCH_JOB 等。角色可以是ROLE_ADMIN，ROLE_USER等。

You could end up in GrantedAuthorities for the roles a user belongs to and the operations a role can perform. The GrantedAuthorities for the roles have the prefix ROLE_ and the operations have the prefix OP_. An example for operation authorities could be OP_DELETE_ACCOUNT, OP_CREATE_USER, OP_RUN_BATCH_JOBetc. Roles can be ROLE_ADMIN, ROLE_USER etc.

你可能最终让你的实体实现 GrantedAuthority 就像这样（伪-code）示例：

You could end up having your entities implement GrantedAuthority like in this (pseudo-code) example:

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

    @OneToMany
    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;

    @OneToMany
    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（）方法返回其所有角色的所有GrantedAuthorities和相应的操作。

The ids of the roles and operations you create in your database would be the GrantedAuthority representation, e.g. "ROLE_ADMIN", "OP_DELETE_ACCOUNT" etc. When a user is authenticated, make sure that all GrantedAuthorities of all its roles and the corresponding operations are returned from the UserDetails.getAuthorities() method.

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

Example: The admin role with id ROLE_ADMIN has the operations OP_DELETE_ACCOUNT, OP_READ_ACCOUNT, OP_RUN_BATCH_JOB assigned to it. The user role with id ROLE_USER has the operation OP_READ_ACCOUNT.

如果管理员登录生成的安全上下文，则将具有GrantedAuthorities：
ROLE_ADMIN， OP_DELETE_ACCOUNT，OP_READ_ACCOUNT，OP_RUN_BATCH_JOB

If an admin logs in the resulting security context will have the GrantedAuthorities: ROLE_ADMIN, OP_DELETE_ACCOUNT, OP_READ_ACCOUNT, OP_RUN_BATCH_JOB

如果用户记录它，它将具有：
ROLE_USER，OP_READ_ACCOUNT

If a user logs it, it will have: ROLE_USER, OP_READ_ACCOUNT

UserDetailsS​​ervice将负责收集这些角色的所有角色和所有操作，并通过返回的UserDetails实例中的getAuthorities（）方法使它们可用。

The UserDetailsService would take care to collect all roles and all operations of those roles and make them available by the method getAuthorities() in the returned UserDetails instance.

这篇关于Spring Security中Role和GrantedAuthority的区别的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！