Подумайте про GrantedAuthority як про "дозвіл" або "право". Ці "дозволи" (як правило) виражаються у вигляді рядків ( getAuthority()методом). Ці рядки дозволяють ідентифікувати дозволи та дозволяти вашим виборцям вирішувати, чи дозволяють їм доступ до чогось.
Ви можете надати різні GrantedAuthoritys (дозволи) користувачам, ввівши їх у контекст безпеки. Зазвичай ви робите це, застосовуючи власну UserDetailsService, яка повертає реалізацію UserDetails, яка повертає необхідні GrantedAuthorities.
Ролі (як вони використовуються у багатьох прикладах) - це лише "дозволи" із умовою іменування, який говорить про те, що роль - це GrantedAuthority, який починається з префікса ROLE_. Більше нічого немає. Роль - це лише GrantedAuthority - «дозвіл» - «право». Ви бачите багато місць у захисті весни, де роль з його ROLE_префіксом обробляється спеціально, як, наприклад, у RoleVoter, де ROLE_префікс використовується як за замовчуванням. Це дозволяє надати імена ролей без ROLE_префікса. До Весняної безпеки 4 цього особливого поводження з "ролями" не дотримувалися дуже послідовно, і повноваження та ролі часто трактувалися однаково (як ви, наприклад,hasAuthority()hasRole()). З Spring Security 4 обробка ролей є більш послідовною, і код, який стосується "ролей" (наприклад RoleVoter, hasRoleвираз тощо), завжди додає ROLE_для вас префікс. Так hasAuthority('ROLE_ADMIN')означає те саме, що hasRole('ADMIN')тому, що ROLE_префікс додається автоматично. Докладніші відомості див. У весняному посібнику з міграції щодо безпеки 3 до 4 .
Але все-таки: роль - це лише авторитет зі спеціальним ROLE_префіксом. Так у Spring безпека 3 @PreAuthorize("hasRole('ROLE_XYZ')")така сама, як @PreAuthorize("hasAuthority('ROLE_XYZ')")і у Spring схожість 4 @PreAuthorize("hasRole('XYZ')")така сама, як у Spring Spring 4 @PreAuthorize("hasAuthority('ROLE_XYZ')").
Що стосується Вашого випадку використання:
Користувачі мають ролі і ролі можуть виконувати певні операції.
Ви можете отримати GrantedAuthoritiesдля ролей, яким належить користувач, і операцій, які може виконувати роль. GrantedAuthoritiesДля ролі префікса ROLE_і операції мають префікс OP_. Прикладом операції влади може бути OP_DELETE_ACCOUNT, OP_CREATE_USER, та OP_RUN_BATCH_JOBт.д. Ролі можуть бути ROLE_ADMIN, ROLE_USER, та ROLE_OWNERт.д.
Можливо, ваші сутності реалізують GrantedAuthorityяк у цьому прикладі (псевдокод):
@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;
}
}
Ідентифікатори ролей та операцій, які ви створюєте у вашій базі даних, будуть представленням GrantedAuthority, наприклад ROLE_ADMIN, OP_DELETE_ACCOUNTтощо. Коли користувач має автентифікацію, переконайтесь, що всі GrantedAuthorities усіх його ролей та відповідні операції повертаються з UserDetails.getAuthorities () метод.
Приклад: адмін роль з ідентифікатором ROLE_ADMINмає операції OP_DELETE_ACCOUNT, OP_READ_ACCOUNT, OP_RUN_BATCH_JOBпокладені на нього. Роль користувача з id 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.