[
https://issues.apache.org/jira/browse/KAFKA-1688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14378100#comment-14378100
]
Don Bosco Durai commented on KAFKA-1688:
----------------------------------------
[~prasadm],
I agree with you, we should support "ALL" or equivalent keyword like (*) in the
default implementation.
I remember the Hierarchical subject brought up during one the google hangout
discussion around authorization. I don't think there were any resolutions
around it.
Does it make sense to make this as a custom implementation feature? So for
OOTB, it would be be just topic name, but anyone who want to implement
hierarchical privileges can parse the topic name and use "." or any other
supported character has delimiter and provide namespace/database like
permissions.
FYI, it seems, hierarchical Topics was discussed back in 2012
https://cwiki.apache.org/confluence/display/KAFKA/Hierarchical+Topics
> Add authorization interface and naive implementation
> ----------------------------------------------------
>
> Key: KAFKA-1688
> URL: https://issues.apache.org/jira/browse/KAFKA-1688
> Project: Kafka
> Issue Type: Sub-task
> Components: security
> Reporter: Jay Kreps
> Assignee: Parth Brahmbhatt
> Fix For: 0.8.3
>
>
> Add a PermissionManager interface as described here:
> https://cwiki.apache.org/confluence/display/KAFKA/Security
> (possibly there is a better name?)
> Implement calls to the PermissionsManager in KafkaApis for the main requests
> (FetchRequest, ProduceRequest, etc). We will need to add a new error code and
> exception to the protocol to indicate "permission denied".
> Add a server configuration to give the class you want to instantiate that
> implements that interface. That class can define its own configuration
> properties from the main config file.
> Provide a simple implementation of this interface which just takes a user and
> ip whitelist and permits those in either of the whitelists to do anything,
> and denies all others.
> Rather than writing an integration test for this class we can probably just
> use this class for the TLS and SASL authentication testing.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
