Grpc Kotlin stubs do not support SecurityContextHolder.getContext()

[mckernant1]

Hello again,

Another kotlin specific problem around the spring SecurityContextHolder.getContext().

I have made a sample commit here with a failing test case

Essentially, SecurityContextHolder.getContext().authentication is null in suspend functions generated by the grpc kotlin stubs. I'm not super familiar with how spring stores this, I believe its threadLocal? Kotlin suspend probably messes this up with how it handles coroutines.

I have added the following block to both sample java grpc-oauth2 and grpc-server-kotlin, and this only fails in grpc-server-kotlin which should confirm its a kotlin stubs issue

if (SecurityContextHolder.getContext().authentication != null) {
    throw RuntimeException(" SecurityContextHolder Authentication not set")
}

I will hopefully have some time to look into this over winter break.

[therepanic]

Hi, @mckernant1.

I believe the versions of grpc-oauth2 and grpc-kotlin you setted conflict with each other. In grpc-oauth2 you have:

if (SecurityContextHolder.getContext().getAuthentication() == null) {
    throw new RuntimeException("Authentication required");
}

And in grpc-kotlin:

if (SecurityContextHolder.getContext().authentication != null) {
    throw RuntimeException(" SecurityContextHolder Authentication not set")
}

You replaced == with !=

[mckernant1]

Ah. Apologies. There were some other issues with the test, so I have fixed those as well.

mckernant1@a9fef0a

It is still failing with the corrected logic https://github.com/mckernant1/spring-grpc/blob/main/samples/grpc-server-kotlin/src/main/kotlin/org/springframework/grpc/sample/GrpcServerService.kt#L21

[dsyer]

AFAIK SecurityContextHolder will never work in a reactive (or equivalently Kotlin coroutine) setting. Probably we need to make some changes to Spring gRPC to make the security context available in a reactive handler (e.g. via ReactiveSecurityContextHolder).

[mckernant1]

Hmmm. Adding the extra reactor dependency doesn't seem ideal, especially if you don't use reactor in any other part of the project. Is there any kotlin specific spring dependency it would make sense to add this to?

[dsyer]

The reactor reference was just to show that this is a broader problem. How does it work with Kotlin and Spring Web (MVC and/or Webflux)?

[mckernant1]

I'm unsure, whenever I have used REST spring boot I never accessed SecurityContextHolder from suspend functions or within a coroutine, so it worked fine.

[mckernant1]

Ok, so I believe I've found a solution here. It is to use GRPC Current context to store the securityContext.

You then use KotlinSecurityContextHolder.getContext().authentication to access the value.

@Configuration
class KotlinSecurityContextInterceptorConfiguration {

    class KotlinServerInterceptor : ServerInterceptor {
        companion object {
            val SECURITY_CONTEXT_KEY: Context.Key<SecurityContext> =
                Context.key("spring-security-context")
        }

        override fun <ReqT, RespT> interceptCall(
            p0: ServerCall<ReqT, RespT>,
            p1: Metadata,
            p2: ServerCallHandler<ReqT, RespT>
        ): ServerCall.Listener<ReqT> {

            val context = SecurityContextHolder.getContext()
            val grpcContext = Context.current()
                .withValue(SECURITY_CONTEXT_KEY, context)

            return Contexts.interceptCall(grpcContext, p0, p1, p2)
        }
    }

    @Bean
    @GlobalServerInterceptor
    fun kotlinSecurityContextInterceptor(): ServerInterceptor {
        return KotlinServerInterceptor()
    }
}

object KotlinSecurityContextHolder {

    fun getContext(): SecurityContext {
        return KotlinServerInterceptor.SECURITY_CONTEXT_KEY.get()
    }

}

I dont really know if this should be integrated into this repo or somewhere else? I can add this to my projects for now, but I am happy to add it in somewhere if it makes sense.

[dsyer]

The Context is a ThreadLocal wrapper just like SecurityContextHolder so I don't know why that would work any better. Are you sure you have a security interceptor in your app?

[mckernant1]

I just copied the sample from the grpc-oauth sample

So i added that to the kotlin sample.
https://github.com/mckernant1/spring-grpc/blob/b78075c6f9f1e293edd428633b2787521827404a/samples/grpc-server-kotlin/src/main/kotlin/org/springframework/grpc/sample/GrpcServerApplication.kt#L27

Do I need to add a separate interceptor outside of the AuthenticationProcessInterceptor ?

It looks like in the documentation it says A context propagation mechanism which can carry scoped-values across API boundaries and between threads. If it is backed by threadlocal, does it have some other mechanism to carry context over?

[dsyer]

It works just the same as SecurityContextHolder. My guess is that we need something else in the Kotlin case to propagate the context into user code. The interceptor is clearly working for me, so I don't know why it would be any different than Java.

[dsyer]

There is a CoroutineContextServerInterceptor designed for this purpose - allows you to transfer thread local context from the caller to the coroutine. We can add one of those if Kotlin coroutines are one the classpath. It's a bit like the StubFactory that we only add in the client if coroutines are present. I have a prototype, just waiting for conformation from the Security team about where some of the code should live. Thanks to @alamnr for the analysis.

[dsyer]

Fixed in 22eb624