A22: Add optional GSSAPI authentication support

[ghost]

For grpc/grpc#16612.

[thelinuxfoundation]

Thank you for your pull request. Before we can look at your contribution, we need to ensure all contributors are covered by a Contributor License Agreement.

After the following items are addressed, please respond with a new comment here, and the automated system will re-verify.

• User @lihalite isn't covered by a CLA. They will need to complete the form at https://identity.linuxfoundation.org/projects/cncf

Regards,
CLA GitHub bot

[carl-mastrangelo]

Please start a discussion thread on the grpc-io mailing list.

[ghost]

Updated with CLA.

[ghost]

Just to follow up; is there still any interest in this?

[srini100]

@a11r, @jiangtaoli2016, seems like a good feature to have in gRPC. Can you please review?

[sanjaypujare]

It will be nice if grpc core (C/C++) can also achieve runtime GSSAPI support instead of at compile/build time although I do understand the limitation posed by C/C++. One possibility is to change the stub implementation as a "shim" layer which will use weak/strong symbols to determine if an actual GSSAPI implementation is linked into the binary.

[ghost]

That makes sense - if it's preferable, I'd be happy to implement it that way.

[sanjaypujare]

This article https://blog.feabhas.com/2013/01/weak-linkage-in-c-programming/ describes the approach and matches what we are trying to achieve.

[sanjaypujare]

If we use this external library approach, is it possible to build GSSAPI-enabled grpc_cli in that project? That way we maintain only one-way dependency (external library depends on grpc core) and we don't have 2 versions of grpc core.

[ghost]

Right now, it's hard to build grpc_cli outside of gRPC itself; if it were possible to build grpc_cli but link it against an existing gRPC installation, instead of having to build it all at once, then the external library approach would be more attractive.

[jiangtaoli2016]

Supporting Kerberbos GSSAPI authentication in gRPC seems a good feature from security point of view.

+@nicolasnoble on build system changes.

[ghost]

Wanted to follow up again; if adding GSSAPI in core is too much trouble, just making it possible to implement custom auth methods client and server-side would be a big help (e.g. grpc/grpc#18459). From our standpoint, only Python is missing the needed API, and only on the server-side - would a proposal or implementation of that be preferable?

We wouldn't have GSSAPI support in grpc_cli (without patching), but that is not as big of a pain point.

[weatherhead99]

very late to this I know but stumbled across this whilst wondering about the feasibility of adding GSS-API support to our internal gRPC based application. Would be extremely welcome to have this from upstream gRPC

[lidavidm]

very late to this I know but stumbled across this whilst wondering about the feasibility of adding GSS-API support to our internal gRPC based application. Would be extremely welcome to have this from upstream gRPC

We ended up implementing this with custom credential/interceptor implementations in each of the languages we needed and using GSSAPI (or a binding to it) directly. Note that full GSSAPI support is tricky in gRPC as you can't have the round trips it requires without a complicated interceptor.

[AshleeNiz7]

very late to this I know but stumbled across this whilst wondering about the feasibility of adding GSS-API support to our internal gRPC based application. Would be extremely welcome to have this from upstream gRPC

We ended up implementing this with custom credential/interceptor implementations in each of the languages we needed and using GSSAPI (or a binding to it) directly. Note that full GSSAPI support is tricky in gRPC as you can't have the round trips it requires without a complicated interceptor.

@lihalite Could you please explain the approach you used or point to some code examples and how did you avoid the roundtrip. Thanks in advance.

[ktdreyer]

@lihalite Could you please explain the approach you used or point to some code examples and how did you avoid the roundtrip. Thanks in advance.

Agreed, I'm interested in implementing this as well.

[ghost]

Sorry - I can't share much/anything as it's proprietary. We don't implement the full roundtrip; we use GSSAPI, but fail if it indicates we need more than one roundtrip.

[alertedsnake]

I also did a proprietary implementation in Python, similar to how @lihalite is describing, also without roundtrips. This was about a year ago, and I'd do it slightly differently now, but I did the credential validation in method in a base servicer class that could be called by an individual RPC to return the current user session. It assumes there's a Negotiate token in the HTTP Authorization header.

It's not currently in use (we're using a different method right now), so I'd have to go revive the code and see what it needs to be viable, but I don't believe it was hard to put together.

I've been following this thread in case an "official" method arose :)

[pseudometric]

Could you please explain the approach you used or point to some code examples and how did you avoid the roundtrip.
Agreed, I'm interested in implementing this as well.

You ”avoid roundtrips” by using a GSSAPI security mechanism which only requires a single message. The common case people are familiar with is the HTTP Negotiate scheme, which specifies the SPNEGO GSSAPI mechanism. SPNEGO is actually a pseudo-mechanism, which will in turn negotiate a concrete mechanism common to the peers (most commonly Kerberos, but it could be something else, e.g. NTLM on Windows); that can involve an arbitrary number of messages. But you don’t have to do this: you can just specify Kerberos directly as the concrete mechanism, e.g. OID 1.3.6.1.5.2.5. If you do that, and do not select mutual authentication (GSS_C_MUTUAL_FLAG), then the exchange consists of a single message from client to server to complete the security context.

Note that since it lacks key confirmation, this is vulnerable to replays within the KRB5_AP_REQ authenticator window, so to be safe it requires a replay cache on the server — which is practically problematic for a number of reasons. Wrapping the exchange in TLS can obviate that need.