Метод configure Spring Security

Настройка Spring Security: от configure к SecurityFilterChain

В старых версиях конфигурация наследовалась от WebSecurityConfigurerAdapter и переопределяла методы configure. Этот стиль устарел и удалён из современного API. Сейчас публикуют обычные бины.

Текущий подход

@Configuration
@EnableMethodSecurity
class SecurityConfiguration {
    @Bean
    SecurityFilterChain security(HttpSecurity http) throws Exception {
        return http
            .authorizeHttpRequests(auth -> auth
                .requestMatchers("/public/**").permitAll()
                .requestMatchers(HttpMethod.DELETE, "/orders/**")
                    .hasAuthority("order:delete")
                .anyRequest().authenticated()
            )
            .build();
    }
}

Несколько цепочек можно разделить через securityMatcher и упорядочить. Для каждого запроса выбирается первая подходящая SecurityFilterChain; правила внутри неё не объединяются автоматически с последующей цепочкой.

AuthenticationManager

Он делегирует подходящим AuthenticationProvider. Для username/password provider обычно использует UserDetailsService и PasswordEncoder. В token-based схеме фильтр/провайдер проверяет token и создаёт authenticated-объект.

ignoring и permitAll

permitAll пропускает запрос через security chain, но разрешает доступ. Полное ignoring исключает security filters и связанные заголовки/контекст, поэтому для динамических endpoint обычно предпочтительнее permitAll.

Вопросы для повторения

1. Почему configure больше не основной вариант? Конфигурация перешла к композиции bean SecurityFilterChain.
2. Как выбирается цепочка при нескольких? Первая совпавшая по matcher с учётом порядка.
3. permitAll удаляет filters? Нет, filters выполняются, но авторизация разрешает запрос.
4. Кто проверяет credentials? AuthenticationManager через подходящий provider.
5. Что делает @EnableMethodSecurity? Включает proxy-based проверки аннотаций на методах.

Связано: Безопасность приложения Spring Security, Spring Proxy.