Unusual Behavior when Integrating with Spring Boot v2.3.3.RELEASE

[jameschensmith]

When I set up a new Spring Boot web project using the latest version with this library (v0.25.2), all routes are unsecure by default.

Description

Initially, I had a project which overrode the default WebSecurityConfigurerAdapter provided by Spring. In this project, I had added this library, and had injected SecurityProblemSupport into my own adapter (initial thought was I had to inject it; upon seeing that SecurityConfiguration was already supplied, I then made attempts without injecting it). This cause very unusual problems, the biggest being intermittent freezing during start up. To separate concerns, I created a simple project, and notice even more unusual patterns happening, such as the routes being unsecure by default. In the simple project, both SecurityConfiguration and DefaultConfigurerAdapter (Spring default) are initialized. If I override it and flip the order, I get the authentication errors, but no problem responses.

Expected Behavior

1. exceptionHandling should apply to all security configurations.
2. Default configuration (i.e. user does not provide their own WebSecurityConfigurerAdapter) should be secure, and should return problem responses.

Actual Behavior

1. exceptionHandling does not apply to all security configurations.
2. Default configuration is unsecure; and when swapping the order does not return problem responses.

Possible Fix

Not sure. When testing with multiple WebSecurityConfigurerAdapter's, the HttpSecurity instances don't follow a pattern of inheritance, which I thought this library was going for (i.e. org.zalando.problem.spring.web.autoconfigure.security.SecurityConfiguration as lowest order, which all other instances of WebSecurityConfigurerAdapter would inherit the exception handling).

Steps to Reproduce

1. Set up new project using Spring Initializr (add Spring Web as dependency)
2. Add this library as a dependency
3. Set up a basic controller route
4. Calling the controller route should go through the security layer

Context

Trying to use this library (the Spring Boot starter) with the default auto-configuration.

Your Environment

• Version used: 0.25.2
• Java Version:

openjdk version "11.0.7" 2020-04-14 LTS
OpenJDK Runtime Environment Zulu11.39+16-SA (build 11.0.7+10-LTS)
OpenJDK 64-Bit Server VM Zulu11.39+16-SA (build 11.0.7+10-LTS, mixed mode)

[whiskeysierra]

If I'm reading the description correctly, there are up to three different issues:

1. Unsecure routes
2. No problem responses
3. intermittent freezing during start up

(I ordered them be severity)

Let's try to tackle them one by one. Can you reproduce 1. in a unit test or sample project? Something you can contribute or share?

[jameschensmith]

Absolutely! Those three points are accurate from what I'm seeing. Again, I may be using the Spring library incorrectly. Let me get a sample project set up and added here for reference. I'll try to get it added by end-of-day my time. 😊 👍

[jameschensmith]

Okay. I was thinking I could get all the examples in one go, but the intermittent issue is really hard to get a working example. So I'm going to start with addressing point 1 (non-secure routes by default). I followed the steps outlined in the first message.

1. Set up new project using Spring Initializr (add Spring Web as dependency)
2. Add this library as a dependency
3. Set up a basic controller route
4. Calling the controller route should go through the security layer

You'll notice that this sets up two instances of org.springframework.security.config.annotation.web.configuration.WebSecurityConfigurerAdapter:

1. org.springframework.boot.autoconfigure.security.servlet.SpringBootWebSecurityConfiguration.DefaultConfigurerAdapter
   a. Order is org.springframework.core.Ordered.LOWEST_PRECEDENCE - 5
2. org.zalando.problem.spring.web.autoconfigure.security.SecurityConfiguration
   a. Order is org.springframework.core.Ordered.LOWEST_PRECEDENCE - 21

Since lower values have higher priority, SecurityConfiguration will get initialized first, then DefaultConfigurerAdapter. You would think that because SecurityConfiguration doesn't authorize any routes while DefaultConfigurerAdapter does, the routes should be secure. But, they aren't.

Also, I read your message so quickly, that I missed where you said one at a time, as well as possibly contributing a unit test where the behavior is not expected. 🙈 I may look into that route as well.

problem-spring-501.zip