Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

A22: Add optional GSSAPI authentication support #101

Open
wants to merge 3 commits into
base: master
from

Conversation

@lihalite
Copy link

lihalite commented Sep 19, 2018

For grpc/grpc#16612.

@thelinuxfoundation
Copy link

thelinuxfoundation commented Sep 19, 2018

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.

Regards,
CLA GitHub bot

* Status: Draft
* Implemented in: C++
* Last updated: 2018/09/19
* Discussion at: N/A

This comment has been minimized.

Copy link
@carl-mastrangelo

carl-mastrangelo Sep 19, 2018

Contributor

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

@lihalite
Copy link
Author

lihalite commented Sep 24, 2018

Updated with CLA.

@lihalite
Copy link
Author

lihalite commented Dec 27, 2018

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

@srini100
Copy link
Contributor

srini100 commented Dec 27, 2018

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

@srini100 srini100 requested review from a11r and jiangtaoli2016 Dec 27, 2018
We may contribute implementations for Java and Python as well, but are
unlikely to do so for other languages gRPC supports. For these
languages, the user would likely provide a GSSAPI implementation at
runtime, not compile-time.

This comment has been minimized.

Copy link
@sanjaypujare

sanjaypujare Dec 27, 2018

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.

This comment has been minimized.

Copy link
@lihalite

lihalite Dec 27, 2018

Author

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

This comment has been minimized.

Copy link
@sanjaypujare

sanjaypujare Dec 27, 2018

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


The Credential could be implemented in an external library, instead of
including it in gRPC core. However, we would like to use grpc_cli,
which is part of gRPC core, with GSSAPI authentication.

This comment has been minimized.

Copy link
@sanjaypujare

sanjaypujare Dec 27, 2018

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.

This comment has been minimized.

Copy link
@lihalite

lihalite Dec 27, 2018

Author

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 jiangtaoli2016 requested a review from nicolasnoble Dec 27, 2018
@jiangtaoli2016
Copy link

jiangtaoli2016 commented Dec 27, 2018

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

+@nicolasnoble on build system changes.

@lihalite
Copy link
Author

lihalite commented Mar 26, 2019

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
Copy link

weatherhead99 commented Feb 1, 2020

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
Copy link

lidavidm commented Feb 3, 2020

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
Copy link

AshleeNiz7 commented May 5, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

10 participants
You can’t perform that action at this time.