Spring Security : Architecture et Chaîne de Filtres

1. La "Magie" de l'Auto-Configuration

Commençons par une expérience simple mais révélatrice. Que se passe-t-il lorsque l'on ajoute simplement Spring Security à un projet Spring Boot ?

Comme votre expérience avec Laravel vous l'a montré, les frameworks modernes privilégient la convention sur la configuration. Spring Boot pousse ce principe très loin.

Pour voir cela en action, regardez la vidéo suivante. Elle montre comment l'ajout d'une seule dépendance transforme instantanément une API ouverte en une application sécurisée.

Ce que vous venez de voir n'est pas de la magie. En ajoutant la dépendance, Spring Boot a automatiquement configuré une chaîne de filtres de sécurité par défaut. Tout comme Laravel utilise des middlewares pour traiter les requêtes HTTP, Spring Security utilise une chaîne de Filter Java Servlet. Chaque requête entrante doit désormais passer à travers cette chaîne avant d'atteindre vos @RestController.

2. L'Architecture de la Chaîne de Filtres (SecurityFilterChain)

Maintenant, levons le voile sur ce qui se passe en coulisses. Spring Security n'est pas un monolithe ; c'est une série de petits composants spécialisés et orchestrés.

Le Point d'Entrée : DelegatingFilterProxy

Quand une requête arrive sur le serveur d'application (Tomcat, par exemple), elle traverse d'abord une chaîne de filtres standard de Java Servlet. Spring Security s'insère dans cette chaîne via un filtre spécial appelé DelegatingFilterProxy. Son unique rôle est de déléguer la requête à une chaîne de filtres gérée par Spring, la SecurityFilterChain.

À l'intérieur de la SecurityFilterChain

Cette chaîne est le cœur de Spring Security. Elle est composée d'une liste ordonnée de filtres, chacun ayant une responsabilité unique. Pour mieux comprendre ces composants, l'article suivant est une excellente référence technique.

Le Flux d'Authentification

Dans cette chaîne, plusieurs filtres collaborent pour authentifier un utilisateur. La vidéo suivante explique verbalement ce flux architectural. C'est un modèle essentiel à comprendre.

Ce découplage est un excellent exemple du principe de responsabilité unique (SRP). Chaque composant a un travail précis, ce qui rend le système extensible et maintenable.

3. Personnaliser la Chaîne de Sécurité

L'auto-configuration est pratique, mais pour une application réelle, nous devons définir nos propres règles. Avec les versions modernes de Spring Security, cela se fait en créant une classe de configuration et en y définissant un Bean de type SecurityFilterChain. C'est l'approche recommandée, qui remplace l'ancienne méthode d'héritage de WebSecurityConfigurerAdapter.

Voyons comment mettre cela en pratique.

Voici un exemple de ce à quoi ressemble une configuration de base. Vous pouvez créer un package com.example.yourapp.config et y placer cette classe SecurityConfig.java.

package com.example.yourapp.config;

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.security.config.annotation.web.builders.HttpSecurity;
import org.springframework.security.config.annotation.web.configuration.EnableWebSecurity;
import org.springframework.security.config.http.SessionCreationPolicy;
import org.springframework.security.web.SecurityFilterChain;

@Configuration
@EnableWebSecurity
public class SecurityConfig {

    @Bean
    public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
        http
            // Puisque nous allons construire une API REST stateless pour React,
            // nous désactivons la protection CSRF qui est utile pour les applications web traditionnelles.
            .csrf(csrf -> csrf.disable())

            // Définition des règles d'autorisation
            .authorizeHttpRequests(authz -> authz
                // Permettre l'accès public à des routes spécifiques (ex: login, register)
                .requestMatchers("/api/auth/**").permitAll()
                // Toutes les autres requêtes doivent être authentifiées
                .anyRequest().authenticated()
            )
            
            // Configurer la gestion de session pour qu'elle soit stateless.
            // Le serveur ne créera pas de session HTTP. Parfait pour les API REST avec JWT.
            .sessionManagement(session -> session.sessionCreationPolicy(SessionCreationPolicy.STATELESS));

        // .httpBasic(Customizer.withDefaults()); // Pour activer l'authentification HTTP Basic

        return http.build();
    }
}

En définissant ce Bean, vous dites à Spring : "Ignore ta configuration de sécurité par défaut et utilise celle-ci que je viens de construire". L'objet HttpSecurity est un builder qui vous permet d'assembler votre chaîne de filtres personnalisée de manière déclarative.

Conclusion

Félicitations ! Vous avez franchi une étape cruciale dans la maîtrise du backend avec Spring. La sécurité peut sembler intimidante, mais en comprenant son architecture, elle devient un outil puissant et flexible.

Points clés à retenir :

• Spring Security protège une application en insérant une chaîne de filtres (SecurityFilterChain) sur le chemin de chaque requête HTTP.
• L'ajout de la dépendance spring-boot-starter-security active une auto-configuration sécurisée par défaut.
• L'architecture d'authentification est modulaire et découplée : Filter -> AuthenticationManager -> AuthenticationProvider -> UserDetailsService.
• La manière moderne de personnaliser la sécurité est de créer un @Bean de type SecurityFilterChain dans une classe @Configuration.
• L'objet HttpSecurity fournit une API fluide pour construire votre chaîne de sécurité personnalisée, en définissant des règles pour les routes (requestMatchers), la gestion de session, etc.

Pour l'instant, notre configuration est très basique. Elle définit ce qui est public et ce qui est privé, mais ne propose pas de mécanisme de connexion robuste adapté à une API REST.

Dans la prochaine leçon, nous allons mettre en pratique ces connaissances pour implémenter un système d'authentification stateless basé sur les JSON Web Tokens (JWT). C'est la méthode standard pour sécuriser les API consommées par des frontends comme React. Nous créerons notre propre filtre JWT pour l'intégrer à la SecurityFilterChain.