reference icon indicating copy to clipboard operation
reference copied to clipboard

GNMI RPC Authentication

Open abhinava opened this issue 8 years ago • 2 comments

Few questions on the authentication scheme as specified here

The spec mentions that username/password per-RPC can be carried within the RPC metadata. If the client (for example) uses C++ GRPC implementation, custom <key, value> pairs in the GRPC metadata can be added using the void ClientContext::AddMetadata method.

Is this sufficient? The issue here is that, the client and the target need offline agreement to ensure correct "keys" are used. That client is expected to use the keys "username" and "password" (Example: {"username": "johndoe", "password":"helloworld"}.

The spec also mentions "Leverage gRPC authentication support." - This is a bit generic and still would require some offline agreement between the server-side implementation and the client.

Any details will be much appreciated. Thanks!

abhinava avatar Dec 30 '17 05:12 abhinava

Adding to my previous point, an alternate implementation approach (as described here) can be used where the server implements a MetadataCredentialsPlugin - But like I mentioned, this still requires that the client and target have some agreement.

abhinava avatar Dec 30 '17 05:12 abhinava

Also, what is the behavior on the GNMI/GRPC client side?

  1. Is it unfair to expect that the client sends <username, password> with every GRPC RPC request? Or, would it just be the username?
  2. Also, given the way GRPC works, the channel establishment ("stub" creation) is done separate from actual RPC. When does the client send the <username, password> data?

Our current plan (to implement GRPC end-point on the network element) is to run the GRPC end-point in InsecureChannelCredential mode. We have a HTTP/TLS reverse proxy in front of the GRPC server to terminate TLS. Once the TLS session is established, all the HTTP/2 requests from the client is transparently forwarded to the GRPC server. Assumption is that every RPC from the client contains <username, password> - The very first RPC that comes on that channel will go through authentication - Local or AAA. Subsequently, as long as the channel stays open, any subsequent RPCs need not be authenticated (just authorization).

Would like to know your thoughts - @robshakir @aashaikh

abhinava avatar Dec 30 '17 18:12 abhinava