Hãy nghĩ về một GrantedAuthority là "sự cho phép" hoặc "quyền". Các "quyền" đó (thông thường) được biểu thị dưới dạng chuỗi (với getAuthority()phương thức). Các chuỗi đó cho phép bạn xác định các quyền và để cử tri của bạn quyết định nếu họ cấp quyền truy cập vào một cái gì đó.
Bạn có thể cấp GrantedAuthority (quyền) khác nhau cho người dùng bằng cách đưa họ vào bối cảnh bảo mật. Bạn thường làm điều đó bằng cách triển khai UserDetailsService của riêng bạn, trả về triển khai UserDetails trả về GrantedAuthorities cần thiết.
Các vai trò (vì chúng được sử dụng trong nhiều ví dụ) chỉ là "quyền" với quy ước đặt tên cho biết vai trò là GrantedAuthority bắt đầu bằng tiền tố ROLE_. Không còn gì nữa. Một vai trò chỉ là GrantedAuthority - "quyền" - "quyền". Bạn thấy rất nhiều vị trí trong bảo mật mùa xuân trong đó vai trò với ROLE_tiền tố của nó được xử lý đặc biệt, ví dụ như trong RoleVoter, trong đó ROLE_tiền tố được sử dụng làm mặc định. Điều này cho phép bạn cung cấp các tên vai trò mà không cần ROLE_tiền tố. Trước Bảo mật mùa xuân 4, việc xử lý "vai trò" đặc biệt này đã không được tuân thủ một cách nhất quán và chính quyền và vai trò thường được đối xử như nhau (ví dụ như bạnhasAuthority()hasRole()). Với Xuân An 4, việc điều trị các vai trò là phù hợp và mã hơn là giao dịch với "vai trò" (như RoleVoter, các hasRolebiểu hiện, vv) luôn thêm ROLE_tiền tố cho bạn. Vì vậy, hasAuthority('ROLE_ADMIN')có nghĩa tương tự như hasRole('ADMIN')vì ROLE_tiền tố được thêm tự động. Xem hướng dẫn di chuyển 3 đến 4 bảo mật mùa xuân để biết thêm thông tin.
Nhưng vẫn: một vai trò chỉ là một cơ quan có ROLE_tiền tố đặc biệt . Vì vậy, trong bảo mật mùa xuân 3 @PreAuthorize("hasRole('ROLE_XYZ')")cũng giống như @PreAuthorize("hasAuthority('ROLE_XYZ')")và trong bảo mật mùa xuân 4 @PreAuthorize("hasRole('XYZ')")cũng giống như vậy @PreAuthorize("hasAuthority('ROLE_XYZ')").
Về trường hợp sử dụng của bạn:
Người dùng có vai trò và vai trò có thể thực hiện các hoạt động nhất định.
Bạn có thể kết thúc GrantedAuthoritiesvới vai trò của người dùng và các hoạt động mà vai trò có thể thực hiện. Các GrantedAuthoritiesvai trò có tiền tố ROLE_và các hoạt động có tiền tố OP_. Một ví dụ cho các cơ quan hoạt động có thể là OP_DELETE_ACCOUNT, OP_CREATE_USER, OP_RUN_BATCH_JOB, vv Vai trò có thể ROLE_ADMIN, ROLE_USER, ROLE_OWNER, vv
Cuối cùng, bạn có thể thực hiện các thực thể của mình GrantedAuthoritynhư trong ví dụ (mã giả) này:
@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 của các vai trò và hoạt động bạn tạo trong cơ sở dữ liệu của bạn sẽ là đại diện GrantedAuthority ROLE_ADMIN, OP_DELETE_ACCOUNTv.v. Khi người dùng được xác thực, hãy đảm bảo rằng tất cả các GrantedAuthorities của tất cả các vai trò của nó và các hoạt động tương ứng đều được trả về từ UserDetails.getAuthorities () phương pháp.
Ví dụ: Vai trò quản trị với id ROLE_ADMINcó các hoạt động OP_DELETE_ACCOUNT, OP_READ_ACCOUNT, OP_RUN_BATCH_JOBgán cho nó. Vai trò người dùng với id ROLE_USERcó hoạt động OP_READ_ACCOUNT.
Nếu một admin logs trong kết quả bối cảnh an ninh sẽ có GrantedAuthorities:
ROLE_ADMIN, OP_DELETE_ACCOUNT, OP_READ_ACCOUNT,OP_RUN_BATCH_JOB
Nếu người dùng đăng nhập nó, nó sẽ có :
ROLE_USER,OP_READ_ACCOUNT
UserDetailsService sẽ chăm sóc để thu thập tất cả các vai trò và tất cả các hoạt động của các vai trò đó và làm cho chúng có sẵn bằng phương thức getAuthorities () trong ví dụ UserDetails được trả về.