Modul 4·Sicherheit

Zugriffsregeln konfigurieren

Das SecurityFilterChain-Bean und die Lambda-DSL: Routen erlauben, authentifizieren und nach Berechtigung einschränken.

18 Min. LesezeitFortgeschritten

Deutsche Übersetzung in Arbeit

Diese Lektion ist noch nicht ins Deutsche übersetzt und wird daher auf Englisch angezeigt. Der Rest der Seite ist vollständig lokalisiert.

Auf dieser Seite

Spring Security's "everything requires login" default is a safe start, but BookVault needs precise rules: the catalog is readable by anyone, health and login are public, and only librarians may change the catalog. You express all of that in one bean.

The SecurityFilterChain bean

Modern Spring Security is configured by declaring a SecurityFilterChain bean using a fluent lambda DSL:

@Configuration
@EnableWebSecurity
class SecurityConfig {

    @Bean
    SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        http
            .authorizeHttpRequests(auth -> auth
                .requestMatchers("/actuator/health", "/api/auth/**").permitAll()
                .requestMatchers(HttpMethod.GET, "/api/books/**").permitAll()
                .requestMatchers(HttpMethod.POST, "/api/books").hasRole("LIBRARIAN")
                .requestMatchers(HttpMethod.PUT, "/api/books/**").hasRole("LIBRARIAN")
                .requestMatchers(HttpMethod.DELETE, "/api/books/**").hasRole("LIBRARIAN")
                .anyRequest().authenticated()
            );
        return http.build();
    }
}

Read the rules top to bottom - they're evaluated in order, so put specific ones before general ones:

permitAll() — open to everyone (health, login, reading the catalog).
hasRole("LIBRARIAN") — only callers with that role (catalog writes).
authenticated() — any logged-in user.
anyRequest().authenticated() — the safety net: anything not matched still needs auth.

Order matters — and end with a catch-all

Rules match first-wins, top to bottom, so a broad rule placed too early can shadow a specific one below it. Always finish with anyRequest().authenticated() (or .denyAll()) so a route you forgot to list isn't accidentally wide open.

Stateless for an API

A REST API authenticated by tokens shouldn't keep server-side sessions. Tell Spring so, and (because there's no browser session/cookie) disable CSRF for the API:

http
    .sessionManagement(s -> s.sessionCreationPolicy(SessionCreationPolicy.STATELESS))
    .csrf(csrf -> csrf.disable());   // safe for a stateless, token-based API

The access rules are the building directory

A SecurityFilterChain is like the posted directory at a building's security desk: "Lobby and café - open to all. Third floor - staff badges only. Everywhere else - sign in." The guard reads it top to bottom and applies the first rule that fits. Your authorizeHttpRequests block is exactly that directory, and the guard is the authorization filter enforcing it.

Write the rules

BookVault needs: GET /api/books/** public; POST/PUT/DELETE /api/books/** LIBRARIAN-only; /actuator/health and /api/auth/login public; everything else requires a logged-in user. Sketch the authorizeHttpRequests rules in the right order, and say why the ordering matters.

In the authorizeHttpRequests DSL, why must rule order be considered carefully?

Key takeaways

Configure access with a SecurityFilterChain bean using the fluent lambda DSL (authorizeHttpRequests).
Rules like permitAll(), authenticated(), and hasRole('LIBRARIAN') map requests to requirements.
Matchers are evaluated top-to-bottom, first-match-wins, so order specific before general and end with a catch-all.
For a token-based API, set SessionCreationPolicy.STATELESS and disable CSRF.
The chain bean is your single, readable source of truth for who can reach what.

War diese Lektion hilfreich?

Diese Seite auf GitHub bearbeiten