springboot Password Generated When Using Resource Server

A default password is generated by Boot in a WebFlux application when a Resource Server is being used.

Create a resource server within a WebFlux application with nothing but the required dependencies

        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-webflux</artifactId>
        </dependency>

        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-security</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.security</groupId>
            <artifactId>spring-security-oauth2-resource-server</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.security</groupId>
            <artifactId>spring-security-oauth2-jose</artifactId>
        </dependency>
        <dependency>
            <groupId>com.nimbusds</groupId>
            <artifactId>oauth2-oidc-sdk</artifactId>
            <version>6.0</version>
        </dependency>

and the yml configuration

spring:
  security:
    oauth2:
      resourceserver:
        jwt:
          issuer-uri: http://idp:9999/auth/realms/demo

and see that the default password is logged the console

PS: This might also happen in servlet environments, but I'm not certain

Comment From: mbhave

Closing in favor of PR #17646.

Comment From: michaeltecourt

Hi @rwinch @mbhave,

I'm only seeing this now as I'm a bit late to the Spring Boot 2.2 party.

The problem is that PR #17646 did not only deactivate password generation, but the whole in-memory authentication manager auto-config. It was a feature, not a bug IMHO.

I actually discussed this a while ago with @dsyer for Spring Boot 1.5 and the old spring-security-oauth module (can't retrieve the GitHub issue). He used to downgrade the order of precedence of the OAuth 2.0 module auto-config, so the actuator remained under HTTP Basic security.

The reasoning : In practice, HTTP Basic is the only actuator security that was accepted by some infrastructure teams I worked with. HTTP Basic is a convenient option for metrics scrapers and old tools like nagios. The infrastructure team configured the same actuator username/password for all micro-services on a given environment.

Even when we use OAuth 2.0 for our HTTP APIs, we keep the actuator with HTTP Basic.

Now it just means we have to create the InMemoryUserDetailsManager ourselves, but I was curious if this was an intended side-effect ?

Comment From: michaeltecourt

• It probably deserves a mention in the Spring Boot 2.2 release notes anyway :)

Comment From: mbhave

@michaeltecourt I think for cases where there's a mix of security models like OAuth2 for the main app and HTTP basic for the actuators, it's better to let the user control it and declare their own AuthenticationManager. However, this change has also caused other failures. Please see #20317. If the outcome of that issue is that the user needs to create their own InMemoryUserDetailsManager, it should be documented in the release notes indeed.

Comment From: michaeltecourt

Well, the missing UserDetailsService is an inconvenience, and a bit incoherent with the fact that Spring Boot provides the spring.security.user config props. Configuring manually an AuthenticationManager feels like the Spring Boot is no longer auto-configuring spring security ?

Comment From: michaeltecourt

The more I think about it, the less I understand the problem with a default password being generated even though OAuth is used.

IMO the framework shouldn't deactivate HTTP Basic Auth implicitely if JWT is enabled.
I would rather have a property to enable/disable explicitely HTTP Basic Auth, like spring.security.http-basic.enabled. Switching it off would make the spring.security.user.* properties ineffective. The password generation should be triggered by HTTP Basic enabled + undefined spring.security.user.password property.

Comment From: mbhave

The spring.security.user.* are not used when the resource server is on the classpath. In Spring Boot 1.x, we've had several issues with the auto-configuration trying to guess and configuring multiple WebSecurityConfigurerAdapters. The security auto-configuration is much simpler now, where, based on the classpath, only one WebSecurityConfigurerAdapter is configured. For anything that's more complex, it's best to let the user decide those rules and configure the ordering of WebSecurityConfigurerAdapters etc.

If you have any more thoughts about this, please comment on the issue I linked above since that is the open issue about the missing AuthenticationManager.

Comment From: wilkinsona

We've opened #20399 to make an update to the release notes.