search

openconfig / reference

This repository contains reference implementations, specifications and tooling related to OpenConfig-based network management.
Apache License 2.0
155 stars 88 forks source link

GNMI RPC Authentication #84

Open abhinava opened 6 years ago

abhinava commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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