Provide Micrometer Context Propagation for SecurityContext

[philsttr]

Add context propagation support via Micrometer Context Propagation for the SecurityContext, between SecurityContextHolder and ReactiveSecurityContextHolder.

This would allow applications to easily cross between the reactive <-> imperative border in either direction, and have the SecurityContext available on both sides.

Examples:

• a WebFlux application could use the handle or tap operators (which propagate from Context to ThreadLocals) to call into imperative code that expects the SecurityContext to be accessible from SecurityContextHolder.
• a Spring WebMVC application could use the captureContext operator (which propagates ThreadLocals to Context) to call into reactive code that expects the SecurityContext to be accessible from ReactiveSecurityContextHolder.

[jzheaux]

Hi, @philsttr, thanks for the suggestion.

Reading the links you provided, I gather that this will be done automatically when an application uses handle/tap and captureContext. I think this would be valuable to add to the documentation, but I'm not yet clear on what if any support Spring Security would need to add. Can you elaborate?

[philsttr]

Hi @jzheaux,

Thanks for considering this feature.

In order to support context propagation of the Spring Security Context, Spring Security would need to:

1. Provide an implementation of ThreadLocalAccessor that operates on the Spring Security Context.
2. Register this implementation with micrometer context propagation. Micrometer context propagation can discover these implementations via Java's ServiceLoader (see ContextRegistry.loadThreadLocalAccessors()), or Spring Security could provide some other mechanism for registering it.

When micrometer context propagation needs to propagate context in either direction (e.g. handle/tap or captureContext), it will invoke all of the registered ThreadLocalAccessors to do so (see DefaultContextSnapshot).

[osi]

spring-graphql provides an implementation of this, https://github.com/spring-projects/spring-graphql/blob/06e485be7a1936d32b7aef470eda218b4f3c17fd/spring-graphql/src/main/java/org/springframework/graphql/execution/SecurityContextThreadLocalAccessor.java

[philsttr]

@osi Spring Security stores a Mono<SecurityContext> in the subscriber context with key SecurityContext.class, but that accessor puts the SecurityContext into the subscriber context with key SecurityContext.class.getName(). So the one from spring-graphql can't just be copied into Spring Security, since it operates on a different key in the subscriber context.

[osi]

ah, i could be wrong! i was looking at the type signature of what is being ***@***.*** - http://fotap.org/~osiOn Sep 28, 2023, at 1:01 AM, Phil Clay ***@***.***> wrote: @osi I'm curious if that one is correct, because Spring Security stores a Mono<SecurityContext> in the subscriber context with key SecurityContext.class, but that accessor puts the SecurityContext directly into the subscriber context with key SecurityContext.class. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>