Pikirkan GrantedAuthority sebagai "izin" atau "benar". "Izin" itu (biasanya) dinyatakan sebagai string (dengan getAuthority()metode). String itu memungkinkan Anda mengidentifikasi izin dan membiarkan pemilih Anda memutuskan apakah mereka memberikan akses ke sesuatu.
Anda dapat memberikan GrantedAuthoritys (izin) yang berbeda kepada pengguna dengan menempatkan mereka dalam konteks keamanan. Anda biasanya melakukannya dengan mengimplementasikan UserDetailsService Anda sendiri yang mengembalikan implementasi UserDetails yang mengembalikan GrantedAuthorities yang diperlukan.
Peran (seperti yang digunakan dalam banyak contoh) hanyalah "izin" dengan konvensi penamaan yang mengatakan bahwa peran adalah GrantedAuthority yang dimulai dengan awalan ROLE_. Tidak ada lagi. Peran hanyalah GrantedAuthority - "izin" - "hak". Anda melihat banyak tempat di keamanan pegas di mana peran dengan ROLE_awalannya ditangani secara khusus seperti misalnya di RoleVoter, di mana ROLE_awalan digunakan sebagai default. Ini memungkinkan Anda untuk memberikan nama peran tanpa ROLE_awalan. Sebelum keamanan Musim Semi 4, penanganan khusus "peran" ini tidak diikuti dengan sangat konsisten dan otoritas dan peran sering diperlakukan sama (seperti misalnya Anda misalnyahasAuthority()hasRole()). Dengan Spring Security 4, perlakuan peran lebih konsisten dan kode yang berhubungan dengan "peran" (seperti RoleVoter, hasRoleekspresi dll) selalu menambahkan ROLE_awalan untuk Anda. Jadi hasAuthority('ROLE_ADMIN')artinya sama hasRole('ADMIN')dengan ROLE_awalan yang ditambahkan secara otomatis. Lihat panduan migrasi 3 hingga 4 keamanan pegas untuk informasi lebih lanjut.
Tapi tetap saja: peran hanyalah otoritas dengan ROLE_awalan khusus . Jadi di Spring keamanan 3 @PreAuthorize("hasRole('ROLE_XYZ')")sama dengan @PreAuthorize("hasAuthority('ROLE_XYZ')")dan di Spring keamanan 4 @PreAuthorize("hasRole('XYZ')")sama dengan @PreAuthorize("hasAuthority('ROLE_XYZ')").
Mengenai kasus penggunaan Anda:
Pengguna memiliki peran dan peran dapat melakukan operasi tertentu.
Anda bisa berakhir GrantedAuthoritiesuntuk peran yang dimiliki pengguna dan operasi yang dapat dilakukan peran. Untuk GrantedAuthoritiesperan memiliki awalan ROLE_dan operasi memiliki awalan OP_. Contoh bagi otoritas operasi bisa OP_DELETE_ACCOUNT, OP_CREATE_USER, OP_RUN_BATCH_JOBdll Peran bisa ROLE_ADMIN, ROLE_USER, ROLE_OWNERdll
Anda dapat menerapkan entitas Anda GrantedAuthorityseperti dalam contoh (pseudo-code) ini:
@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 peran dan operasi yang Anda buat di database Anda akan menjadi representasi GrantedAuthority, misalnya ROLE_ADMIN, OP_DELETE_ACCOUNTdll. Ketika pengguna diautentikasi, pastikan bahwa semua GrantedAuthorities dari semua perannya dan operasi yang sesuai dikembalikan dari UserDetails.getAuthorities () metode.
Contoh: Peran admin dengan id ROLE_ADMINmemiliki operasi OP_DELETE_ACCOUNT, OP_READ_ACCOUNT, OP_RUN_BATCH_JOBditugaskan untuk itu. Peran pengguna dengan id ROLE_USERmemiliki operasi OP_READ_ACCOUNT.
Jika log admin dalam konteks keamanan yang dihasilkan akan memiliki GrantedAuthorities:
ROLE_ADMIN, OP_DELETE_ACCOUNT, OP_READ_ACCOUNT,OP_RUN_BATCH_JOB
Jika pengguna log, itu akan memiliki:
ROLE_USER,OP_READ_ACCOUNT
UserDetailsService akan berhati-hati untuk mengumpulkan semua peran dan semua operasi peran tersebut dan membuatnya tersedia dengan metode getAuthorities () dalam instance UserDetails yang dikembalikan.