Różnica między rolą a GrantedAuthority w Spring Security

Myśl o GrantedAuthority jako o "pozwoleniu" lub "prawie". Te "uprawnienia" są (normalnie) wyrażane jako ciągi znaków (za pomocą metody getAuthority()). Te ciągi pozwalają zidentyfikować uprawnienia i pozwolić głosującym zdecydować, czy przyznają dostęp do czegoś.

Możesz przyznać różne Grantedauthitys (uprawnienia) użytkownikom, umieszczając je w kontekście bezpieczeństwa. Zwykle robisz to, implementując własną usługę UserDetailsService, która zwraca implementację UserDetails, która zwraca wymagane uprawnienia.

Role (ponieważ są używane w wielu przykładach) są po prostu "uprawnieniami" z konwencją nazewnictwa, która mówi, że rola jest GrantedAuthority, która zaczyna się od prefiksu ROLE_. Nic więcej. Rola to tylko Grantauthority - "pozwolenie" - "prawo". W spring security widać wiele miejsc, w których rola z prefiksem ROLE_ jest obsługiwana specjalnie jak np. w Rolevoterze, gdzie prefiks ROLE_ jest używany jako domyślny. Pozwala to na podaj nazwy ról bez prefiksu ROLE_. Przed Spring security 4, Ta specjalna obsługa " ról " nie była przestrzegana bardzo konsekwentnie, a władze i role były często traktowane tak samo (jak widać np. w implementacji metody hasAuthority() W SecurityExpressionRoot - która po prostu wywołuje hasRole()). W Spring Security 4 traktowanie ról jest bardziej spójne i kod, który zajmuje się "rolami" (jak wyrażenie RoleVoter, hasRole itp.) zawsze dodaje ROLE_ prefiks dla Ciebie. Więc hasAuthority('ROLE_ADMIN') oznacza to samo co hasRole('ADMIN') ponieważ prefiks ROLE_ jest dodawany automatycznie. Więcej informacji można znaleźć w przewodniku migracji spring security 3 do 4 .

Ale nadal: rola jest tylko autorytetem ze specjalnym prefiksem ROLE_. Tak więc w Spring security 3 @PreAuthorize("hasRole('ROLE_XYZ')") jest tym samym co @PreAuthorize("hasAuthority('ROLE_XYZ')"), a w Spring security 4 @PreAuthorize("hasRole('XYZ')") jest tym samym co @PreAuthorize("hasAuthority('ROLE_XYZ')").

W odniesieniu do twojego przypadku użycia:

Użytkownicy mają role i role mogą wykonywać pewne szef.

Możesz skończyć w GrantedAuthorities dla ról, do których należy użytkownik i operacji, które może wykonać. GrantedAuthorities dla ról ma prefiks ROLE_, a operacje mają prefiks OP_. Przykładem władz operacyjnych może być OP_DELETE_ACCOUNT, OP_CREATE_USER, OP_RUN_BATCH_JOBitd. Rolami mogą być ROLE_ADMIN, ROLE_USER itp.

Może skończyć się, że Twoje podmioty zaimplementują GrantedAuthority jak w tym (pseudo-kodzie) przykładzie:

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

Identyfikatory ról i operacji Utwórz w swojej bazie danych reprezentację GrantedAuthority, np. "ROLE_ADMIN", "OP_DELETE_ACCOUNT" itp. Gdy użytkownik jest uwierzytelniony, upewnij się, że wszystkie przyznane organy wszystkich jego ról i odpowiadające im operacje są zwracane z UserDetails.metoda getauthority ().

Przykład: Rola administratora o id ROLE_ADMIN ma przypisane do niej operacje OP_DELETE_ACCOUNT, OP_READ_ACCOUNT, OP_RUN_BATCH_JOB. Rola użytkownika o id ROLE_USER ma operację OP_READ_ACCOUNT.

Jeśli administrator loguje się w wynikowym kontekście bezpieczeństwa będzie miał: ROLE_ADMIN, OP_DELETE_ACCOUNT, OP_READ_ACCOUNT, OP_RUN_BATCH_JOB

Jeśli użytkownik go zarejestruje, będzie miał: ROLE_USER, OP_READ_ACCOUNT

UserDetailsService dba o to, aby zebrać wszystkie role i wszystkie operacje tych ról i udostępnić je za pomocą metody getauthority() w zwracanej instancji UserDetails.