Re: [DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism

Thanks for the KIP. Request-level impersonation is going to make the client implementation more complicated. On the producer side, we batch messages per partition. Now, do we have to batch per partition, per user? The consumer client is designed to be single-threaded. So, I am not sure if request-

Re: [DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism

Hi Devs, If there are no more comments, I will start vote on this KIP later this week. Thanks On Fri, Dec 16, 2016 at 12:28 PM, Manikumar wrote: > Hi, > > >> Can you add a sample Jaas configuration using delegation tokens to the >> KIP? >> > > Will add sample Jaas configuration. > > >> To mak

Re: [DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism

Hi, > Can you add a sample Jaas configuration using delegation tokens to the KIP? > Will add sample Jaas configuration. > To make sure I have understood correctly, KAFKA-3712 is aimed at enabling a > superuser to impersonate another (single) user, say alice. A producer using > impersonation wi

Re: [DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism

Hi Rajini, The use case you outline is indeed the one I was thinking of. The concern is indeed what you pointed out, it could be a large change. Ismael On Thu, Dec 15, 2016 at 3:34 AM, Rajini Sivaram wrote: > @Mani > > Can you add a sample Jaas configuration using delegation tokens to the KIP?

Re: [DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism

@Mani Can you add a sample Jaas configuration using delegation tokens to the KIP? Since delegation tokens will be handled differently from other SCRAM credentials, it should work anyway, but it will be good to see an example of the configuration the user provides. It sounds like users provide both

Re: [DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism

@Gwen, @Rajini, As mentioned in the KIP, main motivation for this KIP is to reduce load on Kerberos server on large kafka deployments with large number of clients. Also it looks like we are combining two overlapping concepts 1. Single client sending requests with multiple users/authentications 2.

Re: [DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism

@Gwen @Mani Not sure why we want to authenticate at every request. Even if the token exchange is cheap it still a few calls that need to go through round trip. Impersonation doesn't require authentication for every request. "So a centralized app can create few producers, do the metadata request

Re: [DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism

Hi Rajini, I think it would definitely be valuable to have a KIP for impersonation. Ismael On Wed, Dec 14, 2016 at 4:03 AM, Rajini Sivaram wrote: > It would clearly be very useful to enable clients to send requests on > behalf of multiple users. A separate KIP makes sense, but it may be worth

Re: [DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism

It would clearly be very useful to enable clients to send requests on behalf of multiple users. A separate KIP makes sense, but it may be worth thinking through some of the implications now, especially if the main interest in delegation tokens comes from its potential to enable impersonation. I un

Re: [DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism

That's a good idea. Authenticating every request with delegation token will be useful for impersonation use-cases. But as of now, we are thinking delegation token as just another way to authenticate the users. We haven't think through all the use cases related to impersonation or using delegation t

Re: [DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism

Thinking out loud here: It looks like authentication with a delegation token is going to be super-cheap, right? We just compare the token to a value in the broker cache? If I understood the KIP correctly, right now it suggests that authentication happens when establishing the client-broker connec

Re: [DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism

Ashish, Thank you for reviewing the KIP. Please see the replies inline. > 1. How to disable delegation token authentication? > > This can be achieved in various ways, however I think reusing delegation > token secret config for this makes sense here. Avoids creating yet another > config and for

Re: [DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism

Manikumar, Thanks for the update. As its been a while since any progress was made here, I started working on POC for this. Will be happy to share the progress I have made so far, let's discuss that on parent JIRA. However, more importantly while working on POC, I had following questions that I thi

Re: [DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism

Hi, I would like to reinitiate the discussion on Delegation token support for Kafka. Brief summary of the past discussion: 1) Broker stores delegation tokens in zookeeper. All brokers will have a cache backed by zookeeper so they will all get notified whenever a new token is generated and th

Re: [DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism

Harsha/ Gwen, How do we proceed here? I am willing to help out with here. On Fri, Sep 23, 2016 at 11:41 AM, Gwen Shapira wrote: > Is it updated? are all concerns addressed? do you want to start a vote? > > Sorry for being pushy, I do appreciate that we are all volunteers and > finding time is d

Re: [DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism

Is it updated? are all concerns addressed? do you want to start a vote? Sorry for being pushy, I do appreciate that we are all volunteers and finding time is difficult. This feature is important for anything that integrates with Kafka (stream processors, Flume, NiFi, etc) and I don't want to see t

Re: [DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism

The only pending update for the KIP is to write up the protocol changes like we've it KIP-4. I'll update the wiki. On Thu, Sep 15, 2016 at 4:27 PM Ashish Singh wrote: > I think we decided to not support secret rotation, I guess this can be > stated clearly on the KIP. Also, more details on how c

Re: [DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism

I think we decided to not support secret rotation, I guess this can be stated clearly on the KIP. Also, more details on how clients will perform token distribution and how CLI will look like will be helpful. On Thu, Sep 15, 2016 at 3:20 PM, Gwen Shapira wrote: > Hi Guys, > > This discussion was

Re: [DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism

According to the meeting minutes of KIP hangout on 8/30, it seems the KIP wiki needs some update? KIP48 (delegation tokens): Harsha will update the wiki with more details on how to use delegation tokens and how to configure it. Not sure if that has been done or not. On Thu, Sep 15, 2016 at 3:20

Re: [DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism

Hi Guys, This discussion was dead for a while. Are there still contentious points? If not, why are there no votes? On Tue, Aug 23, 2016 at 1:26 PM, Jun Rao wrote: > Ashish, > > Yes, I will send out a KIP invite for next week to discuss KIP-48 and other > remaining KIPs. > > Thanks, > > Jun > > O

Re: [DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism

Ashish, Yes, I will send out a KIP invite for next week to discuss KIP-48 and other remaining KIPs. Thanks, Jun On Tue, Aug 23, 2016 at 1:22 PM, Ashish Singh wrote: > Thanks Harsha! > > Jun, can we add KIP-48 to next KIP hangout's agenda. Also, we did not > actually make a call on when we sho

Re: [DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism

Thanks Harsha! Jun, can we add KIP-48 to next KIP hangout's agenda. Also, we did not actually make a call on when we should have next KIP call. As there are a few outstanding KIPs that could not be discussed this week, can we have a KIP hangout call next week? On Tue, Aug 23, 2016 at 1:10 PM, Har

Re: [DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism

Ashish, Yes we are working on it. Lets discuss in the next KIP meeting. I'll join. -Harsha On Tue, Aug 23, 2016 at 12:07 PM Ashish Singh wrote: > Hello Harsha, > > Are you still working on this? Wondering if we can discuss this in next KIP > meeting, if you can join. > > On Mon, Jul 18,

Re: [DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism

Hello Harsha, Are you still working on this? Wondering if we can discuss this in next KIP meeting, if you can join. On Mon, Jul 18, 2016 at 9:51 AM, Harsha Chintalapani wrote: > Hi Grant, > We are working on it. Will add the details to KIP about the > request protocol. > > Thanks, > H

Re: [DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism

Hi Grant, We are working on it. Will add the details to KIP about the request protocol. Thanks, Harsha On Mon, Jul 18, 2016 at 6:50 AM Grant Henke wrote: > Hi Parth, > > Are you still working on this? If you need any help please don't hesitate > to ask. > > Thanks, > Grant > > On Thu,

Re: [DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism

Hi Parth, Are you still working on this? If you need any help please don't hesitate to ask. Thanks, Grant On Thu, Jun 30, 2016 at 4:35 PM, Jun Rao wrote: > Parth, > > Thanks for the reply. > > It makes sense to only allow the renewal by users that authenticated using > *non* delegation token m

Re: [DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism

Parth, Thanks for the reply. It makes sense to only allow the renewal by users that authenticated using *non* delegation token mechanism. Then, should we make the renewal a list? For example, in the case of rest proxy, it will be useful for every instance of rest proxy to be able to renew the tok

Re: [DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism

Hi, I am suggesting that we will only allow the renewal by users that authenticated using *non* delegation token mechanism. For example, If user Alice authenticated using kerberos and requested delegation tokens, only user Alice authenticated via non delegation token mechanism can renew. Clients t

Re: [DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism

Parth, Thanks for the reply. A couple of comments inline below. On Tue, Jun 21, 2016 at 10:36 AM, parth brahmbhatt < brahmbhatt.pa...@gmail.com> wrote: > 1. Who / how are tokens renewed? By original requester only? or using > Kerberos > auth only? > My recommendation is to do this only using Ker

Re: [DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism

1. Who / how are tokens renewed? By original requester only? or using Kerberos auth only? My recommendation is to do this only using Kerberos auth and only threw the renewer specified during the acquisition request. 2. Are tokens stored on each broker or in ZK? My recommendation is still to store

Re: [DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism

Harsha, Another question. 9. How would the delegation token be configured in the client? The standard way is to do this through JAAS. However, we will need to think through if this is convenient in a shared environment. For example, when a new task is added to a Storm worker node, do we need to d

Re: [DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism

Just to add on that list. 2. It would be good to document the format of the data stored in ZK. 7. Earlier, there was a discussion on whether the tokens should be propagated through ZK like config/acl/quota, or through the controller. Currently, the controller is only designed for propagating topic

Re: [DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism

>From what I can see, remaining questions are: 1. Who / how are tokens renewed? By original requester only? or using Kerberos auth only? 2. Are tokens stored on each broker or in ZK? 3. How are tokens invalidated / expired? 4. Which encryption algorithm is used? 5. What is the impersonation propos

Re: [DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism

Jun & Ismael, Unfortunately I couldn't attend the KIP meeting when delegation tokens discussed. Appreciate if you can update the thread if you have any further questions. Thanks, Harsha On Tue, May

Re: [DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism

It seems that the links to images in the KIP are broken. Liquan On Tue, May 24, 2016 at 9:33 AM, parth brahmbhatt < brahmbhatt.pa...@gmail.com> wrote: > 110. What does getDelegationTokenAs mean? > In the current proposal we only allow a user to get delegation token for > the identity that it aut

Re: [DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism

110. What does getDelegationTokenAs mean? In the current proposal we only allow a user to get delegation token for the identity that it authenticated as using another mechanism, i.e. A user that authenticate using a keytab for principal us...@example.com will get delegation tokens for that user onl

Re: [DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism

Thanks Rajini. It would probably require a separate KIP as it will introduce user visible changes. We could also update KIP-48 to have this information, but it seems cleaner to do it separately. We can discuss that in the KIP call today. Ismael On Tue, May 24, 2016 at 3:19 PM, Rajini Sivaram < ra

Re: [DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism

Ismael, I have created a JIRA (https://issues.apache.org/jira/browse/KAFKA-3751) for adding SCRAM as a SASL mechanism. Would that need another KIP? If KIP-48 will use this mechanism, can this just be a JIRA that gets reviewed when the PR is ready? Thank you, Rajini On Tue, May 24, 2016 at 2:46

Re: [DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism

Thanks Rajini, SCRAM seems like a good candidate. Gwen had independently mentioned this as a SASL mechanism that might be useful for Kafka and I have been meaning to check it in more detail. Good to know that you are willing to contribute an implementation. Maybe we should file a separate JIRA for

Re: [DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism

SCRAM (Salted Challenge Response Authentication Mechanism) is a better mechanism than Digest-MD5. Java doesn't come with a built-in SCRAM SaslServer or SaslClient, but I will be happy to add support in Kafka since it would be a useful mechanism to support anyway. https://tools.ietf.org/html/rfc7677

Re: [DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism

Parth, Thanks for the explanation. A couple of more questions. 110. What does getDelegationTokenAs mean? 111. What's the typical rate of getting and renewing delegation tokens? That may have an impact on whether they should be directed to the controller. Jun On Mon, May 23, 2016 at 1:19 PM, pa

Re: [DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism

Hi Jun, Thanks for reviewing. * We could add a Cluster action to add acls on who can request delegation tokens. I don't see the use case for that yet but down the line when we start supporting getDelegationTokenAs it will be necessary. * Yes we recommend tokens to be only used/distributed over se

Re: [DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism

Hi Jun, Few of my answers below (since these are things we discussed, or that I thought about) On Mon, May 23, 2016 at 10:35 AM, Jun Rao wrote: > Thanks for the KIP. A few comments. > > 100. This potentially can be useful for Kafka Connect and Kafka rest proxy > where a worker agent will need t

Re: [DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism

Thanks for the KIP. A few comments. 100. This potentially can be useful for Kafka Connect and Kafka rest proxy where a worker agent will need to run a task on behalf of a client. We will likely need to change how those services use Kafka clients (producer/consumer). Instead of a shared client per

Re: [DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism

Hi, Harsha, Just sent out a KIP meeting invite. We can discuss this in the meeting tomorrow. Thanks, Jun On Thu, May 19, 2016 at 8:47 AM, Harsha wrote: > Hi All, >Can we have a KIP meeting around this. The KIP is up for >sometime and if there are any questions lets qui

Re: [DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism

Hi All, Can we have a KIP meeting around this. The KIP is up for sometime and if there are any questions lets quickly hash out details. Thanks, Harsha On Thu, May 19, 2016, at 08:40 AM, parth brahmbhatt wrote: > That is what the hadoop echo system uses so no good

Re: [DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism

That is what the hadoop echo system uses so no good reason really. We could change it to whatever is the newest recommended standard is. Thanks Parth On Thu, May 19, 2016 at 3:33 AM, Ismael Juma wrote: > Hi Parth, > > Thanks for the KIP. I only started reviewing this and may have additional > q

Re: [DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism

Hi Parth, Thanks for the KIP. I only started reviewing this and may have additional questions later. The immediate question that came to mind is our choice of "DIGEST-MD5" even though it's marked as OBSOLETE in the IANA Registry of SASL mechanisms and the original RFC (2831) has been moved to Hist

Re: [DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism

Also comments inline :) > * I want to emphasize that even though delegation tokens are a Hadoop > innovation, I feel very strongly about not adding dependency on Hadoop > when implementing delegation tokens for Kafka. The KIP doesn't imply > such dependency, but if you can clarify... > > > *No had

Re: [DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism

My comments are inline. * The API / RequestResponse section doesn't seem to have good description of the changes to the Kafka Protocol. Sounds like you are proposing new DelegationTokenRequest and RenewTokenRequest (and matching responses), without detailing the contents of the requests and respon

Re: [DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism

Hi Parth and Harsha, Few more comments: * The API / RequestResponse section doesn't seem to have good description of the changes to the Kafka Protocol. Sounds like you are proposing new DelegationTokenRequest and RenewTokenRequest (and matching responses), without detailing the contents of the re

Re: [DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism

Hi Gwen, Can you look at Parth's last reply. Does it answer your concerns. Thanks, Harsha On Wed, May 4, 2016, at 09:25 AM, parth brahmbhatt wrote: > Thanks for reviewing Gwen. The wiki already has details on token > expiration > under token acquisition process >

Re: [DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism

Thanks for reviewing Gwen. The wiki already has details on token expiration under token acquisition process . Current proposal is that tokens will expir

Re: [DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism

Harsha, I was thinking of the Rest Proxy. I didn't see your design yet, but in our proxy, we have a set of producers, which will serve multiple users going through the proxy. Since these users will have different privileges, they'll need to authenticate separately, and can't share a token. Am I m

Re: [DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism

Gwen, On your second point. Can you describe a usecase where mutliple clients ended up sharing a producer and even if they do why can't they not use single token that producer captures. Why would we need multiple clients with different tokens s

Re: [DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism

Sorry for the delay: Two questions that we didn't see in the wiki: 1. Is there an expiration for delegation tokens? Renewal? How do we revoke them? 2. If we want to use delegation tokens for "do-as" (say, submit Storm job as my user), we will need a producer for every job (we can't share them betw

Re: [DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism

Hi, I'm really interested in this KIP too. Giampaolo 2016-05-03 18:12 GMT+02:00 parth brahmbhatt : > Bumping this up one more time, can other committers review? > > Thanks > Parth > > On Tue, Apr 26, 2016 at 9:07 AM, Harsha wrote: > > > Parth, > > Overall current design looks good t

Re: [DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism

Bumping this up one more time, can other committers review? Thanks Parth On Tue, Apr 26, 2016 at 9:07 AM, Harsha wrote: > Parth, > Overall current design looks good to me. I am +1 on the KIP. > > Gwen , Jun can you review this as well. > > -Harsha > > On Tue, Apr 19, 2016, at 09:57 AM

Re: [DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism

Parth, Overall current design looks good to me. I am +1 on the KIP. Gwen , Jun can you review this as well. -Harsha On Tue, Apr 19, 2016, at 09:57 AM, parth brahmbhatt wrote: > Thanks for review Jitendra. > > I don't like the idea of infinite lifetime but I see the Streaming use > cas

Re: [DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism

Thanks for review Jitendra. I don't like the idea of infinite lifetime but I see the Streaming use case. Even for Streaming use case I was hoping there will be some notion of master/driver that can get new delegation tokens at fixed interval and distribute to workers. If that is not the case for w

Re: [DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism

On Mon, Apr 18, 2016 at 11:26 AM, Harsha wrote: > Unifying the two discussion threads on this KIP. > > Here is the response from Jitendra > > "The need for a large number of clients that are running all over the > cluster that authenticate with Kafka brokers, is very similar to the > Hadoop use c

Re: [DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism

Did not realize that you folks were not able to access the discuss thread. Harsha has explicitly added Jitendra and posted his comments, so we should be good to carry on the discussion there. Thanks Harsha! On Mon, Apr 18, 2016 at 11:23 AM, Jitendra Pandey wrote: > Sending it again on the existi

Re: [DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism

Unifying the two discussion threads on this KIP. Here is the response from Jitendra "The need for a large number of clients that are running all over the cluster that authenticate with Kafka brokers, is very similar to the Hadoop use case of large number of tasks running across the cluster that n

Re: [DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism

Sending it again on the existing thread. The need for a large number of clients that are running all over the cluster that authenticate with Kafka brokers, is very similar to the Hadoop use case of large number of tasks running across the cluster that need authentication to Hdfs Namenode. Th

Re: [DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism

Jitendra, Could you post your views on existing discuss thread for KIP-48, http://mail-archives.apache.org/mod_mbox/kafka-dev/201602.mbox/%3cd2f60a7c.61f2c%25pbrahmbh...@hortonworks.com%3E ? On Fri, Apr 15, 2016 at 3:11 PM, Jitendra Pandey wrote: > > The need for a large number of clients that

[DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism

The need for a large number of clients that are running all over the cluster that authenticate with Kafka brokers, is very similar to the Hadoop use case of large number of tasks running across the cluster that need authentication to Hdfs Namenode. Therefore, the delegation token approach does

[DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism

Hi to all, any news about KIP-48? Giampaolo ps: I could not reply to original mail ( http://mail-archives.apache.org/mod_mbox/kafka-dev/201602.mbox/%3cd2f60a7c.61f2c%25pbrahmbh...@hortonworks.com%3E) because I've subscribed after and it's not on my inbox. Please, reply to the original instead of

Re: [DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism

Makes sense to me. Thanks! On Mon, Mar 7, 2016 at 9:25 PM, Harsha wrote: > It doesn't need any release vehicle but still the work can move forward. > If anyone is interested in the KIP please do the review and provide the > comments. > > -Harsha > > On Mon, Mar 7, 2016, at 04:59 PM, Ismael Juma w

Re: [DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism

It doesn't need any release vehicle but still the work can move forward. If anyone is interested in the KIP please do the review and provide the comments. -Harsha On Mon, Mar 7, 2016, at 04:59 PM, Ismael Juma wrote: > I agree that it would be good to have more time to review and discuss > KIP-48.

Re: [DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism

I agree that it would be good to have more time to review and discuss KIP-48. Ismael On Tue, Mar 8, 2016 at 12:55 AM, Gwen Shapira wrote: > Hi Team, > > Since KIP-48 depends on KIP-43, which is already a bit of a risk for > the next release - any chance we can delay delegation tokens to Kafka >

Re: [DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism

Hi Team, Since KIP-48 depends on KIP-43, which is already a bit of a risk for the next release - any chance we can delay delegation tokens to Kafka 0.10.1? With the community working on a release every 3 month, this is not a huge delay. Gwen On Fri, Feb 26, 2016 at 5:11 PM, Ashish Singh wrote:

Re: [DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism

Parth, Thanks again for the awesome write up. Following our discussion from the JIRA, I think it will be easier to compare various alternatives if they are listed together. I am stating below a few alternatives along with a the current proposal. (Current proposal) Store Delegation Token, DT, on ZK

[DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism

Hi, I have filed KIP-48 so we can offer hadoop like delegation tokens in kafka. You can review the design https://cwiki.apache.org/confluence/display/KAFKA/KIP-48+Delegation+token+support+for+Kafka. This KIP depends on KIP-43 and we have also discussed an alternative to proposed design here