La différence entre le Rôle et GrantedAuthority au Printemps de Sécurité

Penser à un GrantedAuthority comme étant une "autorisation" ou "droit". Ces "autorisations" sont (normalement) exprimé sous la forme de chaînes (avec le getAuthority() méthode). Ces chaînes permettent d'identifier les autorisations et laisser les électeurs décider s'ils accordent l'accès à quelque chose.

Vous pouvez accorder différents GrantedAuthoritys (autorisations) pour les utilisateurs en les mettant dans le contexte de sécurité. Normalement, vous faites que par la mise en œuvre de votre propre UserDetailsService qui renvoie un UserDetails de mise en œuvre qui renvoie à la nécessaire GrantedAuthorities.

Rôles (comme ils sont utilisés dans de nombreux exemples) sont des "autorisations" avec une convention de nommage qui dit qu'un rôle est un GrantedAuthority qui commence par le préfixe ROLE_. Il n'y a rien de plus. Un rôle n'est que d'un GrantedAuthority - une "permission" - un "droit". Vous voyez beaucoup d'endroits dans le ressort de la sécurité, où le rôle avec son ROLE_ préfixe est traitée spécialement comme par exemple dans le RoleVoter, où la ROLE_ préfixe est utilisé en tant que par défaut. Cela vous permet de fournir les noms de rôle withtout la ROLE_ préfixe. Avant le Printemps de sécurité 4, ce traitement spécial des "rôles" n'a pas été suivie très régulièrement et les autorités, et que les rôles étaient souvent traités de la même façon (comme, par exemple, vous pouvez le voir dans la mise en œuvre de la hasAuthority() méthode dans SecurityExpressionRoot - qui appelle tout simplement hasRole()). Avec Spring Security 4, le traitement de rôles est plus cohérent et le code qui traite des "rôles" (comme le RoleVoter, le hasRole expression etc.) ajoute toujours le ROLE_ préfixe pour vous. Donc hasAuthority('ROLE_ADMIN') signifie la même chose que hasRole('ADMIN') parce que le ROLE_ préfixe est ajouté automatiquement. Voir le printemps de sécurité de 3 à 4 guide de migration pour de plus amples informations.

Mais encore: un rôle n'est que d'une autorité particulière avec un ROLE_ préfixe. Donc, au Printemps de sécurité 3 @PreAuthorize("hasRole('ROLE_XYZ')") est le même que @PreAuthorize("hasAuthority('ROLE_XYZ')") et au Printemps de sécurité 4 @PreAuthorize("hasRole('XYZ')") est le même que @PreAuthorize("hasAuthority('ROLE_XYZ')").

Au sujet de votre cas d'utilisation:

Les utilisateurs ont des rôles et des rôles peut effectuer certaines opérations.

Vous pourriez vous retrouver dans GrantedAuthorities pour les rôles d'un utilisateur appartient à et les opérations qu'un rôle peut effectuer. Le GrantedAuthorities pour les rôles ont le préfixe ROLE_ et les opérations ont le préfixe OP_. Un exemple pour le fonctionnement des autorités pourrait être OP_DELETE_ACCOUNT, OP_CREATE_USER, OP_RUN_BATCH_JOBetc. Les rôles peuvent être ROLE_ADMIN, ROLE_USER etc.

Vous pourriez finir par avoir votre entités mettre en œuvre GrantedAuthority comme dans cette (pseudo-code) exemple:

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

Les id des rôles et des opérations que vous créez dans votre base de données serait le GrantedAuthority représentation, par exemple, "ROLE_ADMIN", "OP_DELETE_ACCOUNT" etc. Lorsqu'un utilisateur est authentifié, assurez-vous que tous les GrantedAuthorities de tous ses rôles et les opérations correspondantes sont renvoyés à partir de la UserDetails.getAuthorities() la méthode.

Exemple:
Le rôle admin id ROLE_ADMIN a les opérations OP_DELETE_ACCOUNT, OP_READ_ACCOUNT, OP_RUN_BATCH_JOB lui est assigné.
Le rôle de l'utilisateur avec l'id ROLE_USER a l'opération OP_READ_ACCOUNT.

Si un admin journaux dans le contexte de sécurité ont le GrantedAuthorities:
ROLE_ADMIN, OP_DELETE_ACCOUNT, OP_READ_ACCOUNT, OP_RUN_BATCH_JOB

Si un utilisateur se connecte, il aura:
ROLE_USER, OP_READ_ACCOUNT

La 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 le retour de l'UserDetails instance.

Une autre façon de comprendre la relation entre ces concepts est d'interpréter le RÔLE de conteneur des Autorités.

Autorités sont autorisations affinées ciblant une action spécifique couplé avec parfois des données spécifiques à l'étendue ou du contexte. Par exemple, de Lire, d'Écrire, de Gérer, peut représenter différents niveaux de droits d'accès à un compte tenu de l'étendue de l'information.

Aussi, les autorités sont appliquées de profondeur dans le flux de traitement d'une demande, alors que le RÔLE sont filtrées par le filtre de demande de chemin avant d'atteindre le Contrôleur. Les meilleures pratiques de prescrire la mise en œuvre les autorités d'application de passé le Contrôleur dans la couche de gestion.

D'autre part, les RÔLES sont à grain grossier représentation d'un ensemble d'autorisations. Un ROLE_READER serait uniquement en Lecture ou en Vue de l'autorité, tandis qu'un ROLE_EDITOR aurait à la fois en Lecture et en Écriture. Les rôles sont principalement utilisés pour une première projection à la périphérie de la demande de traitement, telles que
http.
...
.antMatcher(...).hasRole(ROLE_MANAGER)

Les Autorités de l'exécution de profondeur dans la demande de flux de processus permet à un grain plus fin à l'application de l'autorisation. Par exemple, un utilisateur peut Lire la permission d'Écriture de premier niveau d'une ressource, mais seulement la Lecture à un sous-ressource. Avoir un ROLE_READER serait de restreindre son droit d'éditer le premier niveau de ressources qu'il a besoin de l'autorisation d'Écriture pour modifier cette ressource mais un @exiger une autorisation préalable de l'intercepteur pourrait bloquer sa tentative de modifier la sous-ressource.

Jake