Hi Peter, I am not entirely sure that I understand what you mean when you say "at application level" to be honest, but I do understand that you want to forego 3rd party tools. However, this would mean that you have to implement some form of trust between your portal which issues the tokens and Kafka which checks the tokens. I am not sure that I'd recommend rolling your own solution here, authentication has a lot of pitfalls that can turn around to bite you. Same thing as what I proposed with Kerberos could be done via certificates of course. If your user requests access to a topic in the portal he uploads a certificate signing request with the topic name encoded in some field (lots of extensions to pick from). The portal signs the request and returns it to the user. When the user now connects to Kafka he does so using this certificate and it should be fairly easy for you to extend the KafkaPrincipalBuilder class and extract the list of these topics from the certificate. Then you'd need to also extend SimpleAclAuthorizer to check for these topics in the principal name and allow access if the topic is present in the certificate.
I am unsure of the benefits of this system over for example having the portal create ACLs in Kafka, when the user is granted access to a topic. One scenario that comes to mind is if you dynamically spin up new clusters, if these new clusters all trust the same ca they would also accept these tokens right away, no need to create ACLs in fresh clusters. But this could also be solved by having a central repository for ACLs that are applied to all clusters regularly.. A drawback of this system is that you'd need to revoke certificates if you want to withdraw access to a topic, which is significantly harder that just deleting an ACL. Anyway, not sure if this helps you at all, just some random musings - if you explain your specific needs a bit more we can discuss further. Kind regards, Sönke On Wed, Oct 25, 2017 at 1:10 PM, Postmann, P. (Peter) < peter.postm...@ing.com.invalid> wrote: > 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. > ----------------------------------------------------------------- > -- Sönke Liebau Partner Tel. +49 179 7940878 OpenCore GmbH & Co. KG - Thomas-Mann-Straße 8 - 22880 Wedel - Germany
