proposal
proposal copied to clipboard
grpc
A22: Add optional GSSAPI authentication support
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
@a11r, @jiangtaoli2016, seems like a good feature to have in gRPC. Can you please review?
Supporting Kerberbos GSSAPI authentication in gRPC seems a good feature from security point of view.
+@nicolasnoble on build system changes.
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. https://github.com/grpc/grpc/issues/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.
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
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.
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.
@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.
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.
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 :)
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.
