Cannot override SecurityFilterChain in Spring Boot context reliably

[dmak]

I have created a small project, which simply defines SecurityFilterChain according to documentation:

@Bean
public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
    http
        .csrf().disable()
        .logout().disable()
        .authorizeRequests()
        .antMatchers( "/**/test").permitAll()
        .anyRequest().authenticated()
        .and().oauth2ResourceServer().jwt();

    return http.build();
}

however it does not override the bean created by OAuth2SecurityFilterChainConfiguration which is picked up by the framework.

To reproduce the issue launch the application with

$ mvn clean install spring-boot:run

and then call the only controller:

$ wget -nv -O - 'http://localhost:8080/spring/test'
Username/Password Authentication Failed.

One can see that because I have disabled the authentication for that very path, HTTP call should complete successfully.

When I was playing around I discovered the following:

• If I change the application initialization from

@SpringBootApplication
@ImportResource("classpath:/application-context.xml")
public class Application extends SpringBootServletInitializer { ...

to equivalent (in that very case)

@SpringBootApplication(scanBasePackages = "spring.test")
public class Application extends SpringBootServletInitializer { ...

it starts working correctly as only one SecurityFilterChain instance is created. It brings me to idea that on some reason DefaultWebSecurityCondition does not sense the SecurityFilterChain created by scanner launched from XML (?)

• Adding @Primary annotation does not help.
• Adding @Order(Ordered.HIGHEST_PRECEDENCE) fixes the issue in that particular small project, but not always in real-life (bigger) projects. I was not able to detect factors that influence that.
• Exclusion of autoconfiguration

@SpringBootApplication(excludeName = "org.springframework.boot.autoconfigure.security.oauth2.resource.servlet.OAuth2ResourceServerJwtConfiguration.OAuth2SecurityFilterChainConfiguration")
public class Application extends SpringBootServletInitializer { ...

does not work, likely due to issue #5427.

P.S. This issue is a follow-up of my comment in issue #10822.

[wilkinsona]

I don't think there's anything that we can do about this in Spring Boot. Spring Framework processes the auto-configuration imports before it considers @ImportResource. As a result, the conditions on the auto-configuration are evaluated before the beans defined by the XML-enabled component scanning are defined. I would recommend moving away from XML-based configuration and using @ComponentScan instead.

If you'd really like @ImportResource to be processed earlier, please open a Spring Framework issue but I suspect it's something that they won't be able to change.

[dmak]

Thanks, your comment actually helped me to workaround/resolve the issue. Would be great if you could also mention since what Spring Boot version such a behavior was introduced (or was it always like that)?

[wilkinsona]

AFAIK, things have always been like this since support for Java configuration was introduced in Spring Framework 3.x.