Considérez une GrantedAuthority comme une "permission" ou un "droit". Ces "autorisations" sont (normalement) exprimées sous forme de chaînes (avec la getAuthority()méthode). Ces chaînes vous permettent d'identifier les autorisations et de laisser vos électeurs décider s'ils accordent l'accès à quelque chose.
Vous pouvez accorder différentes GrantedAuthoritys (autorisations) aux utilisateurs en les plaçant dans le contexte de sécurité. Vous le faites normalement en implémentant votre propre UserDetailsService qui renvoie une implémentation UserDetails qui renvoie les GrantedAuthorities nécessaires.
Les rôles (tels qu'ils sont utilisés dans de nombreux exemples) ne sont que des "autorisations" avec une convention de dénomination qui dit qu'un rôle est une GrantedAuthority qui commence par le préfixe ROLE_. Il n'y a plus rien. Un rôle est juste une GrantedAuthority - une "permission" - un "droit". Vous voyez beaucoup d'endroits dans la sécurité du printemps où le rôle avec son ROLE_préfixe est géré spécialement comme par exemple dans le RoleVoter, où le ROLE_préfixe est utilisé par défaut. Cela vous permet de fournir les noms de rôle sans le ROLE_préfixe. Avant Spring security 4, cette gestion spéciale des «rôles» n'était pas suivie de manière très cohérente et les autorités et les rôles étaient souvent traités de la même manière (comme vous, par exemple,hasAuthority()hasRole()). Avec Spring Security 4, le traitement des rôles est plus cohérent et le code qui traite des "rôles" (comme RoleVoter, l' hasRoleexpression, etc.) ajoute toujours le ROLE_préfixe pour vous. Signifie donc hasAuthority('ROLE_ADMIN')la même chose que hasRole('ADMIN')parce que le ROLE_préfixe est ajouté automatiquement. Consultez le guide de migration Spring Security 3 à 4 pour plus d'informations.
Mais encore: un rôle est juste une autorité avec un ROLE_préfixe spécial . Ainsi, dans Spring, la sécurité 3 @PreAuthorize("hasRole('ROLE_XYZ')")est identique à @PreAuthorize("hasAuthority('ROLE_XYZ')")et dans Spring, la sécurité 4 @PreAuthorize("hasRole('XYZ')")est identique à @PreAuthorize("hasAuthority('ROLE_XYZ')").
Concernant votre cas d'utilisation:
Les utilisateurs ont des rôles et les rôles peuvent effectuer certaines opérations.
Vous pourriez vous retrouver GrantedAuthoritiespour les rôles auxquels appartient un utilisateur et les opérations qu'un rôle peut effectuer. Les GrantedAuthoritiespour les rôles ont le préfixe ROLE_et les opérations ont le préfixe OP_. Un exemple pour les autorités d'exploitation pourraient être OP_DELETE_ACCOUNT, OP_CREATE_USER, OP_RUN_BATCH_JOBetc. Les rôles peuvent être ROLE_ADMIN, ROLE_USER, ROLE_OWNERetc.
Vous pourriez finir par implémenter vos entités GrantedAuthoritycomme dans cet exemple (pseudo-code):
@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;
}
}
Les identifiants des rôles et opérations que vous créez dans votre base de données seraient la représentation GrantedAuthority, par exemple ROLE_ADMIN, OP_DELETE_ACCOUNTetc. Lorsqu'un utilisateur est authentifié, assurez-vous que toutes les GrantedAuthorities de tous ses rôles et les opérations correspondantes sont renvoyées par UserDetails.getAuthorities () méthode.
Exemple: Le rôle d' administrateur avec id ROLE_ADMINa les opérations OP_DELETE_ACCOUNT, OP_READ_ACCOUNT, OP_RUN_BATCH_JOBattribués. Le rôle d'utilisateur avec id ROLE_USERa l'opération OP_READ_ACCOUNT.
Si les journaux d'un administrateur dans le contexte de sécurité résultant auront les GrantedAuthorities:
ROLE_ADMIN, OP_DELETE_ACCOUNT, OP_READ_ACCOUNT,OP_RUN_BATCH_JOB
Si un utilisateur se connecte, il devra:
ROLE_USER,OP_READ_ACCOUNT
UserDetailsService prendrait soin de collecter tous les rôles et toutes les opérations de ces rôles et de les rendre disponibles par la méthode getAuthorities () dans l'instance UserDetails retournée.