I think that¹s one option. What I would offer here is that we need to separate out the concepts of authorization and authentication. Authentication should definitely be modular, so that we can plug in appropriate schemes depending on the organization. For example, you may want client certificates, I may want radius, and someone else is going to want LDAP.
Authorization is the other piece that¹s needed, and that could be internal. Since what you¹re authorizing (topic name, read or write, may rate limiting) is specific to the application, it may not make sense to modularize it. -Todd On 6/3/14, 1:03 PM, "Robert Rodgers" <rsrodg...@gmail.com> wrote: >... client specific presented information, signed in some way, listing >topic permissions. read, write, list. > >TLS lends itself to client certificates. > > >On Jun 3, 2014, at 12:57 PM, Joe Stein <joe.st...@stealth.ly> wrote: > >> 4) Authorization >> >> We should have a policy of "404" for data, topics, partitions (etc) if >> authenticated connections do not have access. In "secure mode" any non >> authenticated connections should get a "404" type message on everything. >> Knowing "something is there" is a security risk in many uses cases. So >>if >> you don't have access you don't even see it. Baking "that" into Kafka >> along with some interface for entitlement (access management) systems >> (pretty standard) is all that I think needs to be done to the core >>project. >> I want to tackle item later in the year after summer after the other >>three >> are complete. >
