HttpSecurity bean has no option to disable defaults

Starting from 5.7 the WebSecurityConfigurerAdapter has been deprecated in favour of using a custom bean for creating a SecurityFilterChain that will inject an HttpSecurity and build it.

The WebSecurityConfigurerAdapter has a constructor field disableDefaults which was used to determine whether defaults should be applied to the configuration or not.

When that flag was set to true then the default configuration and default configurers would not be applied to it. When using the new recommended approach there is no way to disable these defaults.

What would be the recommended approach for disabling the defaults.

Does it perhaps make sense to have an interface like:

public interface HttpSecurityProvider {

    default HttpSecurity create() {
        return create(false);
    }

    HttpSecurity create(boolean disableDefaults);
}

Then instead of doing:

@Configuration
public class SecurityConfiguration {

    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        http
            .authorizeHttpRequests((authz) -> authz
                .anyRequest().authenticated()
            )
            .httpBasic(withDefaults());
        return http.build();
    }

}

we can do:

@Configuration
public class SecurityConfiguration {

    @Bean
    public SecurityFilterChain filterChain(HttpSecurityProvider httpProvider) throws Exception {
        HttpSecurity http = httpProvider.create(true);
        http
            .authorizeHttpRequests((authz) -> authz
                .anyRequest().authenticated()
            )
            .httpBasic(withDefaults());
        return http.build();
    }

}

The approach is only a potential idea. It doesn't have to look like that. However, I do think that it might make sense to expose a functionality that was possible to be used like before.

Start by comparing WebSecurityConfigurerAdapter's disableDefaults behavior with the HttpSecurity and SecurityFilterChain entry points described in the issue. Determine whether a supported way to disable defaults should be exposed and define the expected configuration behavior before proposing an API.