HttpSecurity construction
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.
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);
}
Another option is that since we have the ApplicationContext we could retrieve the ObjectPostProcessor bean and use it as HttpSecurityConfiguration does.
Should we enforce the HttpSecurity defaults like it's done in HttpSecurityConfiguration?