You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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!
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:
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.
The text was updated successfully, but these errors were encountered: