[
https://issues.apache.org/jira/browse/KAFKA-3186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15128067#comment-15128067
]
Ismael Juma commented on KAFKA-3186:
------------------------------------
The CLI is actually meant to work with pluggable authorizers too, see the
following option:
{code}
val authorizerOpt = parser.accepts("authorizer", "Fully qualified class name of
the authorizer, defaults to kafka.security.auth.SimpleAclAuthorizer.")
{code}
Not sure if anyone has managed to use it with a custom authorizer though.
> Kafka authorizer should be aware of principal types it supports.
> ----------------------------------------------------------------
>
> Key: KAFKA-3186
> URL: https://issues.apache.org/jira/browse/KAFKA-3186
> Project: Kafka
> Issue Type: Improvement
> Reporter: Ashish K Singh
> Assignee: Ashish K Singh
>
> Currently, Kafka authorizer is agnostic of principal types it supports, so
> are the acls CRUD methods in {{kafka.security.auth.Authorizer}}. The intent
> behind is to keep Kafka authorization pluggable, which is really great.
> However, this leads to following issues.
> 1. {{kafka-acls.sh}} supports pluggable authorizer and custom principals,
> however is some what integrated with {{SimpleAclsAuthorizer}}. The help
> messages has details which might not be true for a custom authorizer. For
> instance, assuming User is a supported PrincipalType.
> 2. Acls CRUD methods perform no check on validity of acls, as they are not
> aware of what principal types the support. This opens up space for lots of
> user errors, KAFKA-3097 is an instance.
> I suggest we add a {{getSupportedPrincipalTypes}} method to authorizer and
> use that for acls verification during acls CRUD, and make {{kafka-acls.sh}}
> help messages more generic.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
