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?