In general the client authorization will be per RPC based on call metadata. You can also use the TLS session data (such as SAN values from the client cert) but the check will still be per RPC based on the server side interceptor architecture. You might be able to optimize by caching the authorization decisions in the interceptor if you are only going to use peer cert SAN entries for those decisions so your interceptor will be able to use the cache for subsequent calls if there is a cache hit. That depends on the gRPC language you are using but it's not clear which language you are using. On Tuesday, July 27, 2021 at 8:33:24 AM UTC-7 Inian Vasanth wrote:
> Hi, > > I have written Unary and Stream server side interceptors to handle client > requests. Our use case (at the server) is to authorise the client by > looking at the Subject Alternate Name (Domain Name) as part of the x509 > cert presented to the server by matching it against an accepted list. The > problem is, this validation is happening on every client<->server > interaction over a particular gRPC session. We want this to limit it only > once per session during initial handshake? > > Is it possible to tune the interceptors to do this on only on initial > session handshake? > -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/f8c28934-f0b7-4c4c-b975-218efe2d462bn%40googlegroups.com.
