Now that(in boot 2.x) security.basic.enabled is gone having deprecation. "The security auto-configuration is no longer customizable. Provide your own WebSecurityConfigurer bean instead.", it makes sense to add spring.security.enabled=false which would skip security auto-config. Now you need to use something like spring.autoconfigure.exclude with org.springframework.boot.autoconfigure.security.SecurityAutoConfiguration to do a same.

There are cases where you want simple app having a simple flag to disable its security, and i.e. with tests you may want easy way to disable security auto-config.

Comment From: dsyer

@rwinch made the point offline that enabled=false can be misleading, since it would only disable the autoconfig, not the user's own. I believe that is the reason we have spring.aop.auto=false (for instance) - it's not possible to disable AOP completely, only to switch off the autoconfiguration.

Comment From: jvalkeal

Well almost every single enabled property is more or less related to something what boot auto-config classes or their imported configurations do. If people are starting to be worried that some property might be used in a module beyond boot instead in boot, then every property used by boot should be prefixed by spring.boot..

Comment From: snicoll

@jvalkeal That's really not the point.

Comment From: jvalkeal

@snicoll don't understand this wrong, I'm 100% on board to secure everything on default and then forcing users to opt out and removing those security gates if they wish to choose. So many times, especially with UI or rest client setups you're left hanging if stuff doesn't work because security doesn't work or if some other non-security related stuff doesn't work. There has to be a way for a developer to simple disable all security stuff because it's just convenient. We need to make things easy for a dev! It's not always an option to remove security from a classpath.

Comment From: wilkinsona

I think we need to carefully balance the convenience of a boolean against the other ways that you can already achieve a similar thing. Those include:

  • The secure attribute on @AutoConfigureMockMvc
  • Packaging the application without security for integration testing
  • excludeAutoConfiguration attribute on @SpringBootTest (https://github.com/spring-projects/spring-boot/issues/8579)
  • exclude attribute on @SpringBootApplication or @EnableAutoConfiguration
  • spring.autoconfigure.exclude property with the fully-qualified class name of the auto-configuration

Rather than prescribing a solution, it would be helpful to have a list of situations where it would be useful to be able to disable security and then we can evaluate how well, if at all, any of the options above help in that situation.

Comment From: spring-projects-issues

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

Comment From: dsyer

Ping. Don't let me die!

Comment From: wilkinsona

A ping is just kicking the can down the road. Without a response from @jvalkeal to my comment above we might as well just close this.

Comment From: spring-projects-issues

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

Comment From: dsyer

Can kick... Can we disable the issuemaster while we think about this one?

Comment From: wilkinsona

I think that would be counter-productive. It's been almost three weeks already with no input from @jvalkeal and time's rapidly running out for 2.0. If people want some changes to be made, then that thinking needs to be done sooner rather than latter.

Comment From: wilkinsona

In fact, given that we've gone over 14 days with no feedback, I'm going to close this one. We can re-open it if/when someone provides the requested feedback.

Comment From: dsyer

I still think this is important and really quite annoying for users upgrading from 1.5 to 2.0. Apparently management.security.enabled is deprecated (it says so in the additional-spring-configuration-metadata.json), but the "reason" documented doesn't really tell you what the replacement is:

A global security auto-configuration is now provided. Provide your own WebSecurityConfigurer bean instead.

So that's basically telling me to go and take a running jump. How would I enable access to actuator endpoints for testing (for instance)? Or at all, actually? I don't want to provide a WebSecurityConfigurer - I want Spring Boot to do that, like it always did.

Also, it's not deprecated is it (in the sense that it still works but will be removed at some point)? It doesn't work any more.

Comment From: wilkinsona

There's little point in reopening this until someone takes the time to respond in at least some detail to my comment above. Perhaps you could do that, @dsyer? It provides lots of options, particularly for testing.

Comment From: markfisher

cc @jvalkeal

I agree with Dave that this issue should not be closed. If the property is deprecated, it should still work but also have a clear pointer to the new approach.

Comment From: philwebb

Although throwing in a spring.security.enabled property would be pretty easy, I'm not convinced we should jump to that as a solution. It's a little ugly, but setting spring.autoconfigure.exclude=org.springframework.boot.autoconfigure.security.SecurityAutoConfiguration will have the same effect. (@markfisher you're right, we should add a note about that in the deprecation warning). The problem, as I see it, with immediately adding a new property is it is something that will be hard to change later.

Looking at the original request from @jvalkeal, it seems like what we're really asking for is a quick way to disable all security. The spring.security.enabled would give us a quick way to disable auto-configured security, but it won't help with user defined security. What if we could offer a way to bypass security regardless of if it's auto-configured or user-defined?

@rwinch Can you think of any obvious way to do that? Perhaps we could remove the security filter? Or perhaps there's some enhancement that could be made to Spring Security? Would there be any downsides with a bypass flag?

Comment From: dsyer

The spring.security.enabled flag used to do something different. If it would now disable the autoconfigured security on actuator endpoints isn't that a big pit of vulnerability for users to fall into (that's the original reason we separated it into 2 flags)?

Comment From: dsyer

FWIW I also don't like the change in behaviour of secured actuator endpoints. Now they send me a 302 instead of a 401 if I just use autoconfiguration. That's also quite a big change in behaviour and doesn't really make much sense for "API" endpoints (as opposed to front end views).

Comment From: wilkinsona

A 302 doesn't sound right. Where's it trying to send you?

Comment From: dsyer

To the login page (that's what Spring Security generally does). You can send it "X-Requested-With: XMLHttpRequest" and get a 401, but this does seem like an awkward change to foist on actuator users.

Comment From: wilkinsona

Thanks. Agreed on the awkwardness.

Comment From: wilkinsona

I’ve opened https://github.com/spring-projects/spring-boot/issues/10907

Comment From: rwinch

@jvalkeal @dsyer Thanks for your feedback. I'm probably missing something, because based on my understanding of the problem @wilkinsona already provided a solution in https://github.com/spring-projects/spring-boot/issues/10306#issuecomment-330162827.

However, it appears there are still problem(s) to address that I am not understanding. Can you provide a detailed & complete description of the problem(s) you need to solve?

Thanks!

Comment From: dsyer

The comment above (link from rob's last comment) has a pretty good list of all the available features and the scenarios in which they might be used in relation to globally disabling security, so I don't think we need to do that again. The problem is more that there are big changes here and existing users find it confusing. They don't know if they did something wrong. They can't find relevant documentation. The documentation they do find seems irrelevant (probably hasn't made it to the user guide yet, and the configuration properties metadata is too brief, has no links etc.). If they found this thread they might find a solution, but even then there is no copy-paste, or autocomplete help for them. For instance I might decide that management.security.enabled=false can reasonably be replaced in my tests with spring.autoconfigure.exclude, but I don't know the FQN of the class that I need to exclude.

Also, I don't think I know still what the replacement for security.basic.enabled=false would be. How would I customize the application endpoint security without changing the actuator defaults?

Comment From: wilkinsona

For instance I might decide that management.security.enabled=false can reasonably be replaced in my tests with spring.autoconfigure.exclude, but I don't know the FQN of the class that I need to exclude.

A further problem is that that will only work for the auto-configured security. Once the user has configured their own, disabling the auto-configuration isn't going to help. Phil summarised this nicely above:

it seems like what we're really asking for is a quick way to disable all security. The spring.security.enabled would give us a quick way to disable auto-configured security, but it won't help with user defined security. What if we could offer a way to bypass security regardless of if it's auto-configured or user-defined?

Even the secure attribute on @AutoConfigureMockMvc doesn't do that. It just controls whether or not SecurityAutoConfiguration is imported.

I think that brings us back to the question that @philwebb asked @rwinch:

Can you think of any obvious way to do that? Perhaps we could remove the security filter? Or perhaps there's some enhancement that could be made to Spring Security? Would there be any downsides with a bypass flag?

Comment From: rwinch

The answer really depends on the usage scenario. For testing the answer is to not add Spring Security's Filter.

However, Spring Security provides extensive test support which will often mean you do not need to disable security for tests. For example, you can add @WithMockuser and the test will be ran with an authenticated user.

If you are trying to disable security outside of testing, I'm not convinced this is a good idea. However, if you feel that you need to do it, you can choose one of the options below: * Create a WebSecurityConfigurer<WebSecurity> which is in a profile and configure it to ignore all requests * Create a BeanPostProcessor that overrides the springSecurityFilterChain Bean to be a Filter that just continues the FilterChain. * Put your security configuration in a profile and have that profile disabled when you want Security disabled.

Comment From: philwebb

Since this issue has run its course and we've got #10907 to track the specific problem that was identified I'll close it.

Comment From: tomaskroth

This thread went on and on and I really don't think that the major concern was addressed...

I have a @SpringBootTest that used to have security.basic.enabled=false so to test without security. Upgraded to 2 and it no longer works, which is fine, but what should I do then?

There's not a migration path for this documented anywhere. How can I make my SpringBootTest ignore security as I did until a few days ago?

Comment From: wilkinsona

@tomaskroth There are several suggestions in the comments. For example, @rwinch already said this above:

For testing the answer is to not add Spring Security's Filter.

Comment From: wilkinsona

@dalu Please read the comments above. There are several suggestions depending on your exact situation and requirements. If you have further questions, please ask on Stack Overflow or Gitter. As mentioned in the guidelines for contributing, we prefer to use GitHub issues only for bugs and enhancements.

Comment From: wilkinsona

Sorry, but it wasn't clear that you'd read any of the comments above, which of the suggestions you'd tried, or why none of them worked for you. Also, as our guidelines for contributing say, we don't use the issue tracker for questions. That doesn't mean we're snobs, that we think we're infallible, or that we're delegating. It just means that we prefer questions to be asked elsewhere. The team regularly answer questions on Stack Overflow and chat with the community on Gitter.

Comment From: jumal

With recent versions of Spring Boot (2.1.6), when WebFlux and Actuator are used, the following auto configuration classes need to be excluded:

spring.autoconfigure.exclude=org.springframework.boot.autoconfigure.security.reactive.ReactiveSecurityAutoConfiguration,org.springframework.boot.actuate.autoconfigure.security.reactive.ReactiveManagementWebSecurityAutoConfiguration