Open philsttr opened 1 year ago
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?
Hi @jzheaux,
Thanks for considering this feature.
In order to support context propagation of the Spring Security Context, Spring Security would need to:
ThreadLocalAccessor
that operates on the Spring Security Context. 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 ThreadLocalAccessor
s to do so (see DefaultContextSnapshot
).
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
@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.
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
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>
Add context propagation support via Micrometer Context Propagation for the
SecurityContext
, betweenSecurityContextHolder
andReactiveSecurityContextHolder
.This would allow applications to easily cross between the reactive <-> imperative border in either direction, and have the
SecurityContext
available on both sides.Examples:
handle
ortap
operators (which propagate from Context to ThreadLocals) to call into imperative code that expects theSecurityContext
to be accessible fromSecurityContextHolder
.captureContext
operator (which propagates ThreadLocals to Context) to call into reactive code that expects theSecurityContext
to be accessible fromReactiveSecurityContextHolder
.