Description
To configure which observations Security should make, it's needed to provide an ObservationPredicate
. For example, in a boot application you can disable all security observations like so:
@Bean
ObservationRegistryCustomizer<ObservationRegistry> noSpringSecurityObservations() {
ObservationPredicate predicate = (name, context) -> !name.startsWith("spring.security.");
return (registry) -> registry.observationConfig().observationPredicate(predicate);
}
This may feel counter-intuitive and there is thus a temptation to do (name, context) -> name.startsWith("spring.security.*")
which instead would turn off all observations application-wide, except for the Spring Security observations.
Also, an application could reasonably want to turn off the filter chain observations while leaving the authentication and authorization observations intact, and it is cumbersome to require an application to formulate the appropriate logic to honor the various observation names.
One way to simplify this would be to publish a defaults object:
public final class ObservabilityDefaults {
public boolean observeRequests();
public static ObservabilityDefaults.Builder withDefaults();
public static ObservabilityDefaults noObservations();
// ... etc
}
HttpSecurity
and @EnableMethodSecurity
could optionally depend on this bean and apply the correct ObservationWebFilterDecorator
, ObservationAuthenticationManager
, and ObservationAuthorizationManager
instances accordingly.
The nice thing about this approach is that Spring Security could avoid wrapping the filter chain, authentications, and authorizations in more situations, improving runtime performance.
Finally, this allows us to better articulate a change to the defaults in future major versions of Spring Security, for example by leaving a subset of the observations off by default, something that has been requested in spring-projects/spring-boot#34133