...

Discussion thread: user thread, dev thread

JIRA: Will create a JIRA after discussion

...

At the moment Kafka supports 3 main types of security protocol: Plain, SSL, SASL and its variant SASL_SSL and SASL_PLAINTEXT. Behind-the-scenes Kerberos is the only supported authentication mechanism and SSL is the only supported transport protocol. Anyone who is willing to enable authentication security in Kafka they need to properly config Kerberos and SSL. This is sometimes not desirable for users who already have their own authentication security mechanism installed e.g. token based authentication or other SASL mechs. Due to current design of Kafka users with their own choice of authentication mechanism have no way to reuse what they have but have to employ Kerberos. It will be good for Kafka to provide a plug-able way for users to implement their own authentication security mechanism.

Public Interfaces

...

With above changes users who want to include their own authentication logic can set security.protocol to CUSTOMIZED, customized.network.channelbuilder to XYZChannelBuilder where the authentication and SSL secure transport logic resides and add a new listener CUSTOMIZED://host:port in broker.

...

As discussed in KIP-43 an alternative way is to provide a plug-able SASL. But this implementation is bound to SASL implementation only. Authentication users supply must comply with SASL. This KIP provides higher level of abstraction as it is security protocol agnostic and up to users how they want to implement it. This KIP can certainly coexist with KIP-43 which is more focus on SASL mechanism extension.