authentication and identity on the server side

[dsilvasc]

Hi,

The docs at https://developer.lightbend.com/docs/akka-grpc/current/ do a great job of explaining how akka-grpc generates a service trait with GeneratedRequest => Future[GeneratedReply] methods, how to implement that trait, and how to bind that implementation to an Akka HTTP server.

I couldn't find where authentication goes though. The generated methods only take a generated protobuf message argument -- where would we authenticate the request and where would we pass in the caller identity for logging, further authorization checks, or forwarding to other services?

[raboof]

This might be a nice topic for https://discuss.lightbend.com/c/akka/akka-grpc, though indeed this might be a good topic to go into further in the documentation.

There are a number of different kinds of authentication/authorization possible on gRPC connections. One is connection-level authentication: this is for example used on the Google PubSub API's. On the client side, those can be implemented as CallCredentials on the client settings (https://github.com/akka/akka-grpc/blob/master/runtime/src/main/scala/akka/grpc/GrpcClientSettings.scala#L154). There are some libraries that help constructing those credentials, such as https://github.com/google/google-auth-library-java#google-auth-library-oauth2-http . On the server side, those would be implemented by wrapping the generated route in some code that checks the credentials.

This has the obvious limitation that you don't have access to the information in those credentials from your implementation. Additionally, this does not allow for per-call credentials: for that you would need to use the per-call headers. We are planning a 'power API' that should help in both those situations (#201, #179), however actual work on that has not started yet. If you need this, your best bet might be to use the building blocks (generated marshallers/unmarshallers etc) from akka-grpc, but implement your own route based on that. You can of course look at the generated code for inspiration.

A third situation is when you want to add credentials not on the per-call, but on the per-object levels (this is particularly relevant when streaming). In that case I don't think it's possible to avoid putting the credentials inside the actual protobuf payload messages.

[dsilvasc]

Thanks for the quick response. If this is best continued in your discussion group, I can move the conversation there. At the moment, we're looking at the server side, though we're keeping a close eye on the akka-grpc client work as well.

In our services, we often use different auth mechanisms per call. For example, different calls might accept different combinations of Google oauth2, Snapchat oauth2, our app tokens, and our service tokens.

Given that akka-grpc generates a single handler for the service, wrapping it with authentication would apply that to all calls in the service.

At the moment we generate service traits similar to yours:

package $javaPackage

/** service doc... */
trait Async${serviceName} {
  /** rpc doc... */
  def $rpcName(request: $generatedRequestMessage): scala.concurrent.Future[$generatedReplyMessage]
  
   ...
}

I wasn't aware of akka-grpc until recently, and we don't actually use grpc (just protobufs over http post with an in-house protocol similar to Twirp), so we currently hand-write akka-http handlers for each rpc:

case class RPC[RequestMessage <: com.google.protobuf.Message](
  name: String,
  defaultMessage: RequestMessage, // used for parsing
  handle: RequestMessage => Future[com.google.protobuf.Message],
  authenticator: Seq[HttpHeader] => Future[Identity])

val service: Async${serviceName} = ... // the implementation

val protoHandler: HttpRequest => Future[HttpResponse] = makeProtoHandler(servicePackage, serviceName,
  Vector(
    RPC(rpcName, $requestMessage.getDefaultInstance, service.$rpc, googleOAuth(...)),
    RPC(otherRPC, $otherMessage.getDefaultInstance, service.$otherRPC, Auth.any(allowAppTokens, allowServiceTokensFor(serviceName)),
    ...
  )
)

Http().bindAndHandleAsync(protoHandler, "0.0.0.0", port)

I was considering a few options to expose authentication results (some Identity object) to rpc methods:

1. change our custom trait generator to add an Identity argument to each method
2. change our custom trait generator to add a RequestContext argument to each method containing the identity, the execution context, the actor system, materializer, akka-http request, etc.
3. change our custom trait generator to add a Context type parameter to the trait, a context argument to each method, and fill in the type parameter differently per trait implementation (maybe even reusing this trait for clients with a different type of context for that).
4. switch to the akka-grpc code generator and have the identity or context show up in each rpc implementation somehow.

It would be great to do this with akka-grpc. It would also be nice to replace the definition of protoHandler above with the handler that akka-grpc generates.