ClassNotFoundException when management role is set without Spring Security

[snicoll]

To reproduce, create a vanilla app with the actuator (no Spring Security). It works fine but if you specify management.security.role you get this

Caused by: java.lang.NoClassDefFoundError: org/springframework/security/config/http/SessionCreationPolicy
    at org.springframework.boot.actuate.autoconfigure.ManagementServerProperties$Security.<init>(ManagementServerProperties.java:158)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
    at java.lang.reflect.Constructor.newInstance(Constructor.java:408)
    at java.lang.Class.newInstance(Class.java:433)
    at org.springframework.beans.BeanUtils.instantiate(BeanUtils.java:78)
    at org.springframework.beans.AbstractNestablePropertyAccessor.newValue(AbstractNestablePropertyAccessor.java:914)
    at org.springframework.beans.AbstractNestablePropertyAccessor.createDefaultPropertyValue(AbstractNestablePropertyAccessor.java:887)

[snicoll]

okay so the trick is that management.security is null unless binding forces it to be created. If we set management.security.role then the security instance is created by the binder (and that obviously lead to the exception).

I can see the security object being top-level + a condition to enable it which means we'll have to move all the security aspect of the actuator to a separate auto-config element.

[dsyer]

A new bean ManagementSecurityProperties is probably the best solution, but ManagementServerProperties has ignoreUnknownFields = true so we would have to break that to fix this problem, unless we find a way to declare exclusions for ignoreUnknownFields.

[snicoll]

That's #3445

[dsyer]

Indeed. But that one is not marked for 1.3, and this one is (and is marked as a bug). I would argue we need to postpone this and downgrade it to an enhancement.l donut can be done properly in 1.4/2.0.

[snicoll]

Agreed

[snicoll]

Unfortunately, the issue is outside of our control at this stage. The guard makes sure that the Security inner class isn't created but when the binder processes management.security, it first makes sure it has a default value for it before checking it can actually set the value. If that works fine, we end up in NotWritablePropertyException that's going to be ignored by the binder.

Essentially, our guard only works if we don't attempt to bind any element of the management.security namespace. I guess it would be nice to only compute the default value once we have determined that we can actually set it. Maybe @jhoeller has some insight about that?

@philwebb we can workaround the issue by having our own enum for SessionCreationPolicy and something that would translate it back to the actual enum Spring Security is expecting. Or we could have a raw String with value hints metadata. I don't see any other way at this point.

[philwebb]

@snicoll I've gone with the enum option. Ideally we wouldn't change this in 1.4 but a custom was hit by the issue.

[snicoll]

Rather than a sample that acts as an integration test can we please use the test that I've started to craft? It reproduces the exact same thing. If you agree I can replace that.

[wilkinsona]

Yes please, @snicoll

[snicoll]

Reopen to remove the sample and merge the integration test instead