Hi Sönke, Thanks for the fast replay. We don’t want to use Kerberos since we want to do the authorization on Application level and without involvement of a 3rd party during runtime.
-----Original Message----- From: Sönke Liebau [mailto:soenke.lie...@opencore.com.INVALID] Sent: Mittwoch, 25. Oktober 2017 12:37 To: dev@kafka.apache.org Subject: Re: Use self contained tokens instead of ACL The concept you describe sounds similar to what Microsoft calls "claims based authorization". At a high level I should think that using Kerberos as a vehicle to transport the information would be the way to go, as it is established and already supported by Kafka. I believe tickets have a field that can be used for authorization information, so if information about the topics that a user has access to were to be encoded in this field you could probably extend Kafka to extract that information and use it instead of ACLs. I am not well versed in what exactly Microsoft does and how you can control the granting side of things, but I do believe that AD server has support for something along those lines already. The upside of this would be that you don't have to implement anything around security, trust, encryption, etc. because everything is provided by Kerberos. Not much information in here I am afraid, but maybe a useful direction for future research. Kind regards, Sönke On Wed, Oct 25, 2017 at 11:55 AM, Postmann, P. (Peter) < peter.postm...@ing.com.invalid> wrote: > Hi everyone, > > I´m working on a concept to use Kafka with self-contained tokens > (instead of ACL). > > The idea: > > - A client requests access to a certain topic (in some kind of > portal) > > - The owner of the topic approves the request (in some kind of > portal) > > - The client receives a signed tokens which contains the topic > (in some kind of portal) > > - The client sends the token when he connects to Kafka > > - Kafka validates the token and grants access > > Token Format: > > - List of Topics and methods > > o E.g. read /topic1 > > - Expire Date > > - Signature > > Implementation Idea: > > - Create a custom Authorization Class which checks the signature > > - Implement the possibility to send arbitrary data (key->value) > along with the request when the client connects to the cluster > > I´m looking forward for feedback on this approach and would be happy > if you could give me a starting where to start with the implementation > (or if there already is a way to send arbitrary data to a custom Authorizer). > > Kind Regards, > Peter > > ----------------------------------------------------------------- > ATTENTION: > The information in this e-mail is confidential and only meant for the > intended recipient. If you are not the intended recipient, don't use > or disclose it in any way. Please let the sender know and delete the > message immediately. > ----------------------------------------------------------------- > -- Sönke Liebau Partner Tel. +49 179 7940878 OpenCore GmbH & Co. KG - Thomas-Mann-Straße 8 - 22880 Wedel - Germany ----------------------------------------------------------------- ATTENTION: The information in this e-mail is confidential and only meant for the intended recipient. If you are not the intended recipient, don't use or disclose it in any way. Please let the sender know and delete the message immediately. -----------------------------------------------------------------
