Hey Todd, I think you are right on both points.

Maybe instead of modularizing authorization we could instead support some
feature like being able to associate "labels" for the application specific
items (topic name, reads/writes, delete topic, change config, rate
limiting, etc)  and then accept a file or something with a list
entitlements (where name is the "label" and value is some class that gets
run with the ability to extend your own or integrate with some other
system).   e.g. you associate with a topic named "hasCreditCardDataInIt" a
label == "PCIDSS".  Your config would be "PCIDSS" = "CheckForPCIDSS" and
in CheckForPCIDSS code you could do functions like "verify the topic is
going over an encrypted channel return true else false", etc, whatever.

- Joe Stein


On Tue, Jun 3, 2014 at 6:12 PM, Todd Palino <tpal...@linkedin.com.invalid>
wrote:

> 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.
> >
>
>

Reply via email to