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: https://github.com/spring-projects/spring-security/blob/9d876fce820e8d517bd0c947a3113d46082070c5/core/src/main/java/org/springframework/security/authorization/ObservationAuthorizationManager.java#L39

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: https://github.com/spring-projects/spring-boot/commit/07766c436cb89128eac5389d33f76329b758d8df

Comment From: 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?

Comment From: 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: https://github.com/spring-projects/spring-security/blob/5a85375e2ae3561ac943cc9d179dc66bbcb91e25/config/src/main/java/org/springframework/security/config/http/AuthorizationFilterParser.java#L183

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.

Comment From: jzheaux

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

Comment From: 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

Comment From: 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.

Comment From: 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: https://github.com/spring-projects/spring-security/blob/19c55372a3f2f97d1f0ee235f90b38187a8b3a69/config/src/main/java/org/springframework/security/config/annotation/web/builders/HttpSecurity.java#L3002

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

Comment From: jzheaux

You would provide it in that case:

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