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
Rework security auto-configuration #7958
Comments
Any details about rework? Or links to discussion if publicly accessible. |
@kakawait Not yet, no. The work's scheduled for 2.0.0.M5 so it's a little way off yet. |
@wilkinsona Ok thank you for respond I will continue to track the issue. Just to be sure I was not asking about definite implementations but Which part do you want to simplicy and globally how (if you know)? If you understand previous comment like that please do not repeat yourself 🔁 I will wait hihi |
Our main concern is with the various |
@wilkinsona is correct. Part of the problem now is that Boot sometimes works by using multiple |
Ok thank for clarification. I completely understand since I was facing such issues and it takes many time to understand well how order and overriding works when using multiple |
This commit combines security autoconfigurations for management endpoints and the rest of the application. By default, if Spring Security is on the classpath, it turns on @EnableWebSecurity. In the presence of another WebSecurityConfigurerAdapter this backs off completely. A default AuthenticationManager is also provided with a user and generated password. This can be turned off by specifying a bean of type AuthenticationManager, AuthenticationProvider or UserDetailsService. Closes spring-projectsgh-7958
Since the handler interceptors have been removed, web endpoints are all disabled by default to prevent accidental exposure of sensitive information. Closes spring-projectsgh-7958
Since the handler interceptors have been removed, web endpoints are all disabled by default to prevent accidental exposure of sensitive information. Closes gh-7958
Reopening for documentation update. |
Since the autoconfig totally backs off in the presence of a WebSecurityConfigurerAdapter, there is no need to order them ahead of/after the one provided by Spring Boot. See gh-7958
Update security configuration formatting to follow conventions recommended in the Spring Security documentation. See spring-projectsgh-7958
Simplify `AuthenticationManagerConfiguration` following the recent Spring Security auto-configuration updates. See gh-7958
I had a question about the work done in this issue. I posted on StackOverflow because I thought that was the right forum but it's not getting any response organically. The contributors in this issue are probably the right people to answer my question, can you take a look? |
I appreciate the drive to simplify security configuration, but I think it has gone too far. This guide is a useful reference: https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-Security-2.0. (See also https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-2.0-Migration-Guide#actuator-security.) It shows what to do if you want to replace the features in Boot 1.x. In particular: To replace @Bean
public InMemoryUserDetailsManager inMemoryUserDetailsManager() {
return new InMemoryUserDetailsManager(User.withDefaultPasswordEncoder()
.username("user").password("password").roles("USER").build());
} That's a huge amount of boilerplate and it's not discoverable through autocomplete in the IDE. Please can we have Another example. To secure only the actuator endpoints used to be a one liner in a config file: @Configuration
public class ActuatorSecurityConfigurer extends WebSecurityConfigurerAdapter {
@Override
public void configure(HttpSecurity http) throws Exception {
http
.authorizeRequests()
.requestMatchers(EndpointRequest.to("status")).permitAll()
.requestMatchers(EndpointRequest.to("info")).permitAll()
.requestMatchers(EndpointRequest.toAnyEndpoint()).hasRole("ACTUATOR")
.antMatchers("/**").permitAll()
.and()
.httpBasic();
}
} It's too much boilerplate IMO. |
I agree that's a lot of boilerplate, but I'm not sure that bringing back 1.x's solution to this problem was for Boot to auto-configure multiple, ordered If we need to make a trade-off between being understandable and being concise, then I would much prefer the former over the latter. I think 2.0 gets that trade-off right. Perhaps there's something that can be done to reduce the boilerplate that's needed and we should spend some time thinking about it. Right now, I'm not sure how it can be done without repeating the mistakes of 1.x. |
I've opened #10963. |
That would be a good start (and it's fine to back off once user adds a On the |
Also, I've just realized that the example above only works for Servlet apps. I don't even know how to start with a WebFlux app, but it's probably something similar. An annotation could hide the details. |
If we do provide deeper integration with Actuator and Security, I would not do this via an annotation as this provides little value as soon as the user needs to provide any sort of customization. Instead, I'd lean towards providing something that hooks into the Spring Security DSL. In its simplest form it might look something like this: http
.apply(actuatorSecurity()).and()
... any customization ...; Likely under the covers |
I've raised #10968 for the actuator security suggestion. |
As discussed with @rwinch we would like to significantly simplify security configuration in 2.0.
The text was updated successfully, but these errors were encountered: