Unary and Stream Interceptors - Per session authorization

[Inian Vasanth]

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?

[sanjay...@google.com]

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.

[Amit Saha]

Did you mean that for streaming communication, you only want the
authnz to happen during the RPC call and not subsequent message
exchanges?


>
> --
> 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+u...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/7ac235e8-d769-4793-8c43-ac01bc84eab7n%40googlegroups.com.

[Eric Anderson]

What language are you using? Go?

In Go you can provide a tls.Config with VerifyPeerCertificate set. Other languages will vary or not be readily possible. In Java you'd implement an X509ExtendedTrustManager.

Note that restricting at connection establishment commonly still needs to be combined with restricting on a per-method or per-resource basis, simply because your ACLs can be per-method or per-resource as well.

--