[
https://issues.apache.org/jira/browse/KAFKA-4185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15571363#comment-15571363
]
Edoardo Comar commented on KAFKA-4185:
--------------------------------------
Hi [~piyushvijay] I see that a KIP has been proposed as a wider solution (works
for other mechanisms too)
https://cwiki.apache.org/confluence/display/KAFKA/KIP-86%3A+Configurable+SASL+callback+handlers
> Abstract out password verifier in SaslServer as an injectable dependency
> ------------------------------------------------------------------------
>
> Key: KAFKA-4185
> URL: https://issues.apache.org/jira/browse/KAFKA-4185
> Project: Kafka
> Issue Type: Improvement
> Components: security
> Affects Versions: 0.10.0.1
> Reporter: Piyush Vijay
> Fix For: 0.10.0.2
>
>
> Kafka comes with a default SASL/PLAIN implementation which assumes that
> username and password are present in a JAAS
> config file. People often want to use some other way to provide username and
> password to SaslServer. Their best bet,
> currently, is to have their own implementation of SaslServer (which would be,
> in most cases, a copied version of PlainSaslServer
> minus the logic where password verification happens). This is not ideal.
> We believe that there exists a better way to structure the current
> PlainSaslServer implementation which makes it very
> easy for people to plug-in their custom password verifier without having to
> rewrite SaslServer or copy any code.
> The idea is to have an injectable dependency interface PasswordVerifier which
> can be re-implemented based on the
> requirements. There would be no need to re-implement or extend
> PlainSaslServer class.
> Note that this is commonly asked feature and there have been some attempts in
> the past to solve this problem:
> https://github.com/apache/kafka/pull/1350
> https://github.com/apache/kafka/pull/1770
> https://issues.apache.org/jira/browse/KAFKA-2629
> https://issues.apache.org/jira/browse/KAFKA-3679
> We believe that this proposed solution does not have the demerits because of
> previous proposals were rejected.
> I would be happy to discuss more.
> Please find the link to the PR in the comments.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
