It'd be handy to be able to construct an instance of HttpSecurity independently from an WebSecurityConfigurerAdapter.

In theory, this is possible since HttpSecurity has a public constructor, but that's currently impractical due to its abstract nature:

public HttpSecurity(ObjectPostProcessor<Object> objectPostProcessor,
            AuthenticationManagerBuilder authenticationBuilder,
            Map<Class<?>, Object> sharedObjects)

If there were a simpler way to build an HttpSecurity instance, then code like the following would be within reach:

Map<String, Filter> proxies = new HashMap<>();
// ...

String tenant = resolveTenant(request);
Filter proxy = proxies.computeIfAbsent(tenant, k -> {
    HttpSecurity http = // construct
    // configure by tenant
    return new FilterChainProxy(http.build());
});
proxy.doFilter(request, response, chain);

which seems like a powerful tool for multi-tenancy.

Comment From: jzheaux

Given that ObjectPostProcessor is quite an advanced feature, one option would be to introduce a noop ObjectPostProcessor and then introduce a constructor like so:

public HttpSecurity(ApplicationContext context) {
    this(NOOP_OBJECT_POST_PROCESSOR, 
        withPasswordEncoder(context), Collections.singletonMap(ApplicationContext.class, context));
}

private static AuthenticationManagerBuilder withPasswordEncoder(ApplicationContext context) {
    WebSecurityConfigurerAdapter.LazyPasswordEncoder passwordEncoder = 
        new WebSecurityConfigurerAdapter.LazyPasswordEncoder(context);
    return new WebSecurityConfigurerAdapter.DefaultPasswordEncoderAuthenticationManagerBuilder(
        NOOP_OBJECT_POST_PROCESSOR, passwordEncoder);
}

Comment From: marcusdacoregio

Another option is that since we have the ApplicationContext we could retrieve the ObjectPostProcessor bean and use it as HttpSecurityConfiguration does.

Comment From: marcusdacoregio

Should we enforce the HttpSecurity defaults like it's done in HttpSecurityConfiguration?