Разница между ролью и GrantedAuthority в весенней безопасности

подумайте о GrantedAuthority как о "разрешении"или " праве". Эти "разрешения" (обычно) выражаются в виде строк (с getAuthority() метод). Эти строки позволяют идентифицировать разрешения и позволяют вашим избирателям решать, предоставляют ли они доступ к чему-либо.

вы можете предоставить различные GrantedAuthoritys (разрешения) для пользователей, поместив их в контекст безопасности. Обычно вы делаете это, реализуя свой собственный UserDetailsService, который возвращает UserDetails реализация, которая возвращает необходимые GrantedAuthorities.

роли (как они используются во многих примерах) - это просто "разрешения" с Соглашением об именах, в котором говорится, что роль является GrantedAuthority, которая начинается с префикса ROLE_. Больше ничего нет. Роль - это просто предоставленное право - "разрешение" - "право". Вы видите много мест в spring security, где роль с ее ROLE_ префикс обрабатывается специально, например, в RoleVoter, где ROLE_ префикс используется по умолчанию. Это позволяет предоставить имена ролей без ROLE_ префикс. До Spring security 4 Эта специальная обработка "ролей" не соблюдалась очень последовательно, и власти и роли часто обрабатывались одинаково (как вы, например, можете видеть в реализации hasAuthority() метод SecurityExpressionRoot - который просто называет hasRole()). С Spring Security 4 обработка ролей более последовательна и код, который имеет дело с "ролями" (например RoleVoter на hasRole выражение etc.) всегда добавляет ROLE_ префикс для вас. Так что hasAuthority('ROLE_ADMIN') означает то же самое, что и hasRole('ADMIN') потому что ROLE_ префикс добавляется автоматически. См. безопасность весны 3 до 4 руководство по миграции для получения дополнительной информации.

но все же: роль-это просто авторитет со специальным ROLE_ префикс. Так что весной безопасность 3 @PreAuthorize("hasRole('ROLE_XYZ')") это то же самое, что @PreAuthorize("hasAuthority('ROLE_XYZ')") а весной безопасность 4 @PreAuthorize("hasRole('XYZ')") это то же самое, что @PreAuthorize("hasAuthority('ROLE_XYZ')").

что касается вашего варианта использования:

пользователи имеют роли и роли могут выполнять определенные операции.

вы можете оказаться в GrantedAuthorities для ролей, к которым принадлежит пользователь, и операций, которые может выполнять роль. Элемент GrantedAuthorities для ролей есть префикс ROLE_ и операции имеют префикс OP_. Примером для оперативных органов может быть OP_DELETE_ACCOUNT,OP_CREATE_USER,OP_RUN_BATCH_JOB etc. Роли могут быть ROLE_ADMIN, ROLE_USER так далее.

вы могли бы в конечном итоге ваши сущности реализовать GrantedAuthority как в этом (псевдокоде) примере:

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

идентификаторы ролей и операций, которые вы создаете в своей базе данных, будут представлять GrantedAuthority, например "ROLE_ADMIN", "OP_DELETE_ACCOUNT" и т. д. Когда пользователь проходит проверку подлинности, убедитесь, что все предоставленные полномочия всех его ролей и соответствующих операций возвращаются из UserDetails.getAuthorities() метод.

пример: Роль администратора с идентификатором ROLE_ADMIN имеет назначенные ей операции OP_DELETE_ACCOUNT, OP_READ_ACCOUNT, OP_RUN_BATCH_JOB. Роль пользователя с идентификатором ROLE_USER имеет операцию OP_READ_ACCOUNT.

если администратор регистрируется в результирующем контексте безопасности будет иметь GrantedAuthorities: ROLE_ADMIN, OP_DELETE_ACCOUNT, OP_READ_ACCOUNT, OP_RUN_BATCH_JOB

если пользователь регистрирует его, он будет иметь: ROLE_USER, OP_READ_ACCOUNT

в UserDetailsService позаботится о том, чтобы собрать все роли и все операции этих ролей и сделать их доступными с помощью метода getAuthorities() в возвращенном экземпляре UserDetails.