Gestion des autorisations avec @PreAuthorize

1. Fondations : Rôles et Permissions

Avant de coder, clarifions deux concepts fondamentaux : l'authentification et l'autorisation.

Pour résumer :

• Authentification : Vérifie l'identité de l'utilisateur (login/mot de passe, JWT). C'est ce que nous avons fait jusqu'à présent.
• Autorisation : Vérifie si un utilisateur authentifié a le droit d'effectuer une action ou d'accéder à une ressource. C'est notre sujet du jour.

Dans Spring Security, l'autorisation s'appuie sur les GrantedAuthority. Ce sont les privilèges accordés à l'utilisateur authentifié. Un Role (comme ROLE_ADMIN) est simplement un type de GrantedAuthority. Votre implémentation de UserDetailsServiceImpl est chargée de convertir les rôles stockés en base de données pour votre entité User en une collection de GrantedAuthority.

Une subtilité importante : le préfixe ROLE_

Par défaut, quand vous utilisez l'expression hasRole('ADMIN'), Spring Security cherche en réalité une autorité nommée ROLE_ADMIN. C'est une convention. Si vos rôles en base de données sont stockés sans ce préfixe (par ex. "ADMIN"), vous avez deux options :

1. Ajouter manuellement le préfixe dans votre UserDetailsServiceImpl lors de la création des SimpleGrantedAuthority.
2. Désactiver ce comportement en ajoutant un Bean à votre configuration de sécurité.

Pour un contrôle total et éviter les surprises, de nombreux développeurs choisissent de désactiver ce préfixe. L'article de tonux-dev explique comment faire cela, dans la section "Nom du rôle Préfixe par défaut", si cela vous intéresse. Pour nos exemples, nous supposerons que le préfixe ROLE_ est géré correctement.

2. Annotation vs Configuration : Deux approches pour l'autorisation

Spring Security propose deux manières principales de configurer les règles d'autorisation :

1. Basée sur la configuration (SecurityFilterChain) : Les règles sont centralisées dans votre classe WebSecurityConfig en chaînant des appels sur http.authorizeHttpRequests(). C'est utile pour des règles globales.
2. Basée sur les annotations (@PreAuthorize) : Les règles sont placées directement sur les méthodes des contrôleurs. C'est idéal pour un contrôle fin et une meilleure lisibilité, car la règle de sécurité est juste à côté du code qu'elle protège.

Compte tenu de votre objectif de maîtriser les architectures propres et les bonnes pratiques, nous allons nous concentrer sur l'approche par annotations, qui est plus modulaire et plus facile à maintenir dans les grands projets.

Pour bien comprendre la première approche avant de nous plonger dans la seconde, regardez comment la vidéo suivante met en place une restriction via la configuration.

L'inconvénient de cette méthode est que le fichier de configuration peut vite devenir complexe et difficile à lire si vous avez beaucoup de règles spécifiques.

3. Mise en œuvre avec @PreAuthorize

Passons à la pratique. L'annotation @PreAuthorize nous permet d'utiliser le langage d'expression de Spring (SpEL) pour définir des règles d'accès complexes directement sur nos méthodes de contrôleur.

Étape 1 : Activer la sécurité au niveau des méthodes

Cette fonctionnalité n'est pas activée par défaut. Vous devez l'activer explicitement dans votre configuration de sécurité.

@Configuration
@EnableWebSecurity
@EnableMethodSecurity // <-- AJOUTEZ CETTE ANNOTATION !
public class WebSecurityConfig {
    // ... votre configuration existante
}

Dans les versions plus anciennes de Spring Boot (avant la 3), l'annotation était @EnableGlobalMethodSecurity(prePostEnabled = true). L'annotation @EnableMethodSecurity est la version moderne et simplifiée.

Étape 2 : Sécuriser les méthodes du contrôleur

Maintenant que la fonctionnalité est activée, nous pouvons utiliser @PreAuthorize sur n'importe quelle méthode de bean Spring (contrôleurs, services, etc.).

Créons un contrôleur d'exemple pour tester cela :

@RestController
@RequestMapping("/api/boards")
public class BoardController {

    @GetMapping("/all")
    public String allAccess() {
        return "Contenu public.";
    }

    @GetMapping("/user")
    @PreAuthorize("hasRole('USER') or hasRole('MODERATOR') or hasRole('ADMIN')")
    public String userAccess() {
        return "Contenu pour les utilisateurs connectés.";
    }

    @GetMapping("/mod")
    @PreAuthorize("hasRole('MODERATOR')")
    public String moderatorAccess() {
        return "Tableau de bord du modérateur.";
    }

    @GetMapping("/admin")
    @PreAuthorize("hasRole('ADMIN')")
    public String adminAccess() {
        return "Tableau de bord de l'administrateur.";
    }
}

Ces exemples, inspirés du document [PDF] Authentification (JWT) et gestion des Roles, montrent comment utiliser hasRole() et des opérateurs logiques comme or.

Étape 3 : Démonstration pratique et test

La meilleure façon de comprendre est de le faire. La vidéo suivante vous guide pas à pas pour déplacer la logique de sécurité de la configuration vers les annotations sur un nouveau contrôleur.

4. Au-delà des rôles : les permissions granulaires

Parfois, les rôles ne sont pas assez précis. Imaginez que vous ayez des ADMIN qui peuvent lire les données et des SUPER_ADMIN qui peuvent en plus les supprimer. Au lieu de multiplier les rôles, on peut utiliser des permissions (ou autorités).

C'est là que hasAuthority('permission_name') devient plus puissant que hasRole(). Un rôle peut être vu comme un ensemble de permissions.

Avec cette approche, on peut vérifier une permission spécifique : @PreAuthorize("hasAuthority('DELETE_USER')").

La dernière partie de la vidéo de chillotech explique brillamment comment implémenter ce modèle avancé. C'est une excellente pratique qui rend votre système de sécurité beaucoup plus flexible et maintenable.

Même si vous ne l'implémentez pas entièrement maintenant, comprendre cette distinction entre rôle et permission est fondamental pour concevoir des systèmes professionnels et évolutifs.

Conclusion

Félicitations ! Vous maîtrisez désormais un aspect crucial de la sécurité des applications : l'autorisation. En plaçant des règles de sécurité directement là où elles s'appliquent, votre code devient plus lisible, plus sûr et plus facile à faire évoluer.

Points clés à retenir :

• L'autorisation (@PreAuthorize) complète l'authentification (JWT) en contrôlant ce que les utilisateurs peuvent faire.
• L'annotation @EnableMethodSecurity est indispensable pour activer la sécurité au niveau des méthodes.
• @PreAuthorize avec le langage SpEL (hasRole, hasAuthority, or, and) offre un contrôle d'accès puissant et flexible.
• L'approche par annotations est souvent préférable à la configuration centralisée pour sa lisibilité et sa modularité.
• Distinguer les rôles des permissions (hasAuthority) permet de construire des systèmes d'autorisation beaucoup plus granulaires et professionnels.

Dans notre prochaine leçon, nous conclurons les bases de la sécurité en nous assurant que les données les plus sensibles de vos utilisateurs, leurs mots de passe, sont stockées de la manière la plus sûre possible. Nous verrons comment utiliser BCryptPasswordEncoder pour hacher les mots de passe avant de les sauvegarder en base de données.