Properly Injecting AuthenticationManager into Custom Filters with Spring Security Java Configuration

In the Spring Security framework, AuthenticationManager is a core component responsible for handling user credentials and returning Authentication objects. When migrating from traditional XML configuration to Java-based configuration, developers often encounter dependency injection issues, particularly when injecting AuthenticationManager into custom filters.

Problem Background and Error Analysis

In the provided case, the developer attempted to inject AuthenticationManager into a custom filter, TokenAuthenticationProcessingFilter, using the @Autowired annotation, but encountered a NoSuchBeanDefinitionException. The error indicates that no qualifying AuthenticationManager bean is found in the Spring container. This occurs because, in Java configuration, AuthenticationManager is not automatically exposed as a Spring bean unless explicitly configured.

Solution: Override the authenticationManagerBean Method

According to the best answer, the key solution is to override the authenticationManagerBean method in a subclass of WebSecurityConfigurerAdapter. This method exposes the AuthenticationManager as a Spring bean, making it available for dependency injection. Below is a complete configuration example:

@Configuration
@EnableWebSecurity
public class SecurityConfig extends WebSecurityConfigurerAdapter {

    @Autowired
    private UserDetailsService userDetailsService;

    @Autowired
    private PasswordEncoder passwordEncoder;

    @Override
    protected void configure(AuthenticationManagerBuilder auth) throws Exception {
        auth.userDetailsService(userDetailsService)
            .passwordEncoder(passwordEncoder);
    }

    @Bean(name = BeanIds.AUTHENTICATION_MANAGER)
    @Override
    public AuthenticationManager authenticationManagerBean() throws Exception {
        return super.authenticationManagerBean();
    }

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http.sessionManagement()
                .sessionCreationPolicy(SessionCreationPolicy.STATELESS)
            .and()
            .exceptionHandling()
                .authenticationEntryPoint(authenticationEntryPoint)
                .accessDeniedHandler(accessDeniedHandler)
            .and()
            .addFilterBefore(tokenAuthenticationProcessingFilter(), UsernamePasswordAuthenticationFilter.class);
    }

    @Bean
    public TokenAuthenticationProcessingFilter tokenAuthenticationProcessingFilter() throws Exception {
        TokenAuthenticationProcessingFilter filter = new TokenAuthenticationProcessingFilter("/rest/user/authenticate");
        filter.setAuthenticationManager(authenticationManagerBean());
        filter.setAuthenticationSuccessHandler(authenticationSuccessHandler);
        filter.setAuthenticationFailureHandler(authenticationFailureHandler);
        return filter;
    }
}

In this configuration, the authenticationManagerBean() method is annotated with @Bean and specifies the name BeanIds.AUTHENTICATION_MANAGER, which is the standard bean ID used internally by Spring Security. By calling super.authenticationManagerBean(), it returns the AuthenticationManager instance built via the configure(AuthenticationManagerBuilder) method, thereby registering it as a bean in the Spring container.

Adjustments in Custom Filters

In the custom filter, TokenAuthenticationProcessingFilter, AuthenticationManager can now be safely injected. It is recommended to remove the @Autowired-annotated setter methods and instead set the manager manually in the configuration class via constructor or setter methods for better clarity and control. For example, in the configuration class's tokenAuthenticationProcessingFilter() method, use filter.setAuthenticationManager(authenticationManagerBean()).

In-Depth Understanding and Best Practices

The core of this solution lies in understanding the bean lifecycle in Spring Security. In Java configuration, AuthenticationManager is typically built via AuthenticationManagerBuilder in the configure method but is not registered as a Spring bean by default. Overriding the authenticationManagerBean method addresses this, ensuring bean availability.

Additionally, developers should consider version compatibility. While this article is based on Spring Security 3.2, the method remains applicable in later versions, as the core mechanisms of WebSecurityConfigurerAdapter and AuthenticationManager are stable. In practice, tailor the configuration to specific business needs, such as adding extra authentication providers or custom exception handling.

By following these steps, developers can successfully migrate from XML to Java configuration, avoid common dependency injection errors, and build more robust security systems.