Hi, Mayuresh, Thanks for the KIP. A few comments below.
1. It seems the problem that you are trying to address is that java principal returned from KafkaChannel may have additional fields than name that are needed during authorization. Have you considered a customized PrincipleBuilder that extracts all needed fields from java principal and squeezes them as a json in the name of the returned principal? Then, the authorizer can just parse the json and extract needed fields. 2. Could you explain how the default authorizer works now? Currently, the code just compares the two principal objects. Are we converting the java principal to a KafkaPrincipal there? 3. Do we need to add the following method in PrincipalBuilder? The configs are already passed in through configure() and an implementation can cache it and use it in buildPrincipal(). It's also not clear to me where we call the new and the old method, and whether both will be called or one of them will be called. Principal buildPrincipal(Map<String, ?> principalConfigs); 4. The KIP has "If users use there custom PrincipalBuilder, they will have to implement there custom Authorizer as the out of box Authorizer that Kafka provides uses KafkaPrincipal." This is not ideal for existing users. Could we avoid that? Thanks, Jun On Fri, Feb 3, 2017 at 11:25 AM, Mayuresh Gharat <gharatmayures...@gmail.com > wrote: > Hi All, > > It seems that there is no further concern with the KIP-111. At this point > we would like to start the voting process. The KIP can be found at > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=67638388 > > Thanks, > > Mayuresh >
