Ability to customize the `AuthorizationObservationConvention`

[braunsonm]

Expected Behavior

The ability to customize the obersations made by spring security (adjust low/high cardinality keys, etc). For instance I would like to add the high cardinality key of the Principal#getName() to my traces.

Current Behavior

You cannot currently customize the provided AuthorizationObservationConvention without registering your own ObersationRegistry which replaces the entire registry.

Context

Here is where the AuthorizationObservationConvention is currently used and instantiated as part of the class:

spring-security/core/src/main/java/org/springframework/security/authorization/ObservationAuthorizationManager.java

Line 39 in 9d876fc

private final AuthorizationObservationConvention convention = new AuthorizationObservationConvention();

In spring boot, they made adjustments ahead of the 3.0 release to make their own observation conventions customizable for HTTP clients. It would make sense for spring-security to do the same thing here and allow providing your own conventions/overridden conventions.

See spring boots implementation here: spring-projects/spring-boot@07766c4

[jzheaux]

I think this would be useful, @braunsonm.

Are you able to provide a PR? If so, it would be nice to add the same setter to ObservationReactiveAuthorizationManager.

For consistency, would you also have time to add the equivalent setter to ObservationAuthenticationManager and ObservationReactiveAuthorizationManager?

[braunsonm]

Sorry I'm not too familiar with the spring-security codebase. Would a setter on those classes work? From what I can tell they are instantiated from FactoryBean's like here:

spring-security/config/src/main/java/org/springframework/security/config/http/AuthorizationFilterParser.java

Line 183 in 5a85375

public static final class RequestMatcherDelegatingAuthorizationManagerFactory

So in order to implement this you would want a setter on the RequestMatcherDelegatingAuthorizationManagerFactory for AuthorizationObservationConvention and move the default out of ObservationAuthorizationManager and into RequestMatcherDelegatingAuthorizationManagerFactory. Let me know if I'm on the right track of thinking here.

[jzheaux]

Hi, @braunsonm. AuthorizationFilterParser is for XML support. Is that what you are trying to use?

[braunsonm]

No. I suppose I'm not sure where the change needs to be made, I don't see where the bean is created so we can pass in the user provided ObservationAuthenticationManager

[jzheaux]

I think the only changes that are needed are to add the setters. Applications can publish AuthenticationManager as a @Bean and can wire AuthorizationManager into authorizeHttpRequests and AuthorizationManagerBefore/AfterMethodInterceptor. I don't anticipate changes to spring-security-config at this point.

[braunsonm]

Am I mistaken? I don't think that would work because the ObservationAuthenticationManager is only created if you don't provide your own AuthenticationManager implementation:

spring-security/config/src/main/java/org/springframework/security/config/annotation/web/builders/HttpSecurity.java

Line 3002 in 19c5537

setSharedObject(AuthenticationManager.class, new ObservationAuthenticationManager(registry, manager));

Unless you are wanting anyone who customizes their AuthenticationManager to also extend the ObservationAuthenticationManager, which means we should make it non-final.

[jzheaux]

You would provide it in that case:

@Bean 
AuthenticationManager authenticationManager() {
    AuthenticationManager myAuthenticationManager = ...;
    ObservationAuthenticationManager observing = new ObservationAuthenticationManager(myAuthenticationManager);
    observing.setAuthenticationConvention(...);
    return observing;
}