Spring actuator will disable any configuration that has been specified in the spring boot configuration YAML file unless you have an explicit WebSecurityConfigurerAdapter defined.

It took me a while to figure out why specifically integrating the new Spring Security 5.2 native support for saml2login which is demonstrated in the minimalist sample application. Simply adding actuator to that application will disable saml2. The reasons are the rules associated with the rules associated with ManagementWebSecurityAutoConfiguration.

@Configuration(proxyBeanMethods = false)
@ConditionalOnClass(WebSecurityConfigurerAdapter.class)
@ConditionalOnMissingBean(WebSecurityConfigurerAdapter.class)
@ConditionalOnWebApplication(type = ConditionalOnWebApplication.Type.SERVLET)
@AutoConfigureBefore(SecurityAutoConfiguration.class)
@AutoConfigureAfter({ HealthEndpointAutoConfiguration.class, InfoEndpointAutoConfiguration.class,
        WebEndpointAutoConfiguration.class, OAuth2ClientAutoConfiguration.class,
        OAuth2ResourceServerAutoConfiguration.class })
@Import({ ManagementWebSecurityConfigurerAdapter.class, WebSecurityEnablerConfiguration.class })
public class ManagementWebSecurityAutoConfiguration {}

There are several problems with this:

  1. Boot tries to get configuration into the config files, not into the context of the application.
  2. It is defined to perform this configuration before SecurityAutoConfiguration which is again trying to circumvent the users configuration and enforce the configuration defined by actuator.
  3. The underlying cause is the forceful nature of ManagementWebSecurityConfigurerAdapter enforcing forms based authentication.

In this the simplest separation of concerns is to NOT perform the following in ManagementWebSecurityConfigurerAdapter:

http.formLogin(Customizer.withDefaults());
http.httpBasic(Customizer.withDefaults());

Comment From: brettryan

I've created this project which demonstrates the issue.

Comment From: wilkinsona

Thanks for the sample. We try out best to assume positive intent, but it's difficult when faced with something being described as "wrong" (above) and "insane" (in the sample's README). We may well have made a mistake, but describing our work as insane isn't a great way to start a discussion about getting things to work the way that you would like.

Comment From: mbhave

We are missing an @AutoConfigureAfter(Saml2RelyingPartyAutoConfiguration.class) on the ManagementWebSecurityAutoConfiguration. We added it for the OAuth ones but missed it for the SAML security configuration.

Comment From: brettryan

@wilkinsona, you are very correct and I do apologise for my strong and forced reactions. I had spent the better part of the day tracking what was causing this leaving me jaded for spring boot which I've avoided adopting for years favouring spring framework directly due to auto-configuration very often doing something I don't want it to do.

@mbhave, thank you very much for this. It's one of those tricky things that I see of how do you juggle all the conflicting spring dependencies.

SAML2 is new and only came in spring-security 5.2 which is why it was missed. This though, is why I think that the actuator has overlapping concerns that will likely cause another problem in the future due to the fragile nature of depending on changes in spring-security. I realise this can't be undone now as it would break those not providing their own configuration.

Comment From: mbhave

@brettryan Yes there is a chance that this could happen but there was a reason for adding a separate actuator auto-configuration when actuator is on the classpath. It lets us allow unauthenticated access to the health and info endpoints in the default case without entangling the WebSecurityConfigurerAdapters too much.