Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HttpSecurity construction #7449

Open
jzheaux opened this issue Sep 17, 2019 · 3 comments
Open

HttpSecurity construction #7449

jzheaux opened this issue Sep 17, 2019 · 3 comments
Labels
in: web An issue in web modules (web, webmvc) type: enhancement A general enhancement

Comments

@jzheaux
Copy link
Contributor

jzheaux commented Sep 17, 2019

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.

@jzheaux jzheaux added this to the General Backlog milestone Sep 17, 2019
@rwinch rwinch added the status: waiting-for-triage An issue we've not yet triaged label Nov 16, 2021
@jzheaux jzheaux added in: web An issue in web modules (web, webmvc) type: enhancement A general enhancement and removed status: waiting-for-triage An issue we've not yet triaged labels Mar 31, 2022
@jzheaux
Copy link
Contributor Author

jzheaux commented Mar 31, 2022

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);
}

@marcusdacoregio
Copy link
Contributor

marcusdacoregio commented Aug 17, 2022

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

@marcusdacoregio
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: web An issue in web modules (web, webmvc) type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

3 participants