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

HTTP Bridge OpenId-Connect authentication and authorization #305

Open
uqmat opened this issue Aug 26, 2019 · 2 comments
Open

HTTP Bridge OpenId-Connect authentication and authorization #305

uqmat opened this issue Aug 26, 2019 · 2 comments

Comments

@uqmat
Copy link

uqmat commented Aug 26, 2019

Are there any plans to integrate an OpenId-Connect based authentication and authorization mechanism into the HTTP bridge?
I'm thinking of something in the line of:

  • use "bearer only" token authentication
  • integrate OID provider for authorization
  • configure HTTP bridge either with explicit roles on a per endpoint / per topic basis,
    or use a role name pattern (e.g. ROLE__READ or the like)

In this way it would be possible to leverage OID connect authorization mechanisms by using the HTTP bridge, and not having to resort to the ACL-based (vanilla Kafka) authorization. The latter being not that easily integrated with an existing OID provider and its role configuration.

@scholzj
Copy link
Member

scholzj commented Aug 26, 2019

This is something we are looking for in Kafka it self. But I'm not sure it is so clear cut for the HTTP Bridge. The question is of how much of integrating it into the HTTP Bridge directly would be worth it compared to just fronting it with some OAuth proxy or for example some API Gateway which will always have better features in this area than we would ever be able to build into the bridge.

So I would say that this is maybe still not fully decided.

@uqmat
Copy link
Author

uqmat commented Aug 27, 2019

Yes, I completely agree, the best thing would be for such a feature to be available in Kafka.
And yes, using dedicated components which already solve the problem at hand is probably a better (or at least less error-prone) way to go.
Thanks for sharing your thoughts!

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

No branches or pull requests

2 participants