Page History

...

Kafka server and client will have a new configuration option sasl.mechanisms to specify the list of enabled mechanisms. In order to plug in any SASL mechanism including custom mechanisms, mechanisms will be specified as String rather than an enum with a restricted set of values.  GSSAPI will be used as the default mechanism without mechanism negotiation for interoperability of new clients with 0.9.0.0 brokers. If a list of mechanisms is specified, a mechanism is selected by the client after exchange of mechanisms supported in the server, as described laterClients may enable only one mechanism and the mechanism name is sent to the server before any SASL authentication packets are sent, if the mechanism is not GSSAPI. Server may enable multiple mechanisms.

SASL callback handler

Kafka server and client will have a new configuration option sasl.callback.handler.class to provide a callback handler class. Default callbacks are included in Kafka for the mechanisms which have an implementation in Kafka (GSSAPI and PLAIN). Default client callback handler obtains authentication id and password from the public and private credentials of the Subject respectively as String values. Configurable callbacks will enable other mechanisms to be used with Kafka without any changes to Kafka code. The callback handler interface has been derived from the implementation for GSSAPI and PLAIN mechanisms. Apart from Subject, configuration properties and mechanism are provided to the callback object to enable custom mechanisms to be added without any changes to Kafka.

SASL properties

The current implementation does not specify any properties when the SaslClient or SaslServer is constructed. To make the Kafka implementation flexible with pluggable mechanisms, all properties specified for Kafka client/server will be passed to the SaslClient/SaslServer. These include all properties specified by the user including properties not defined in Kafka, so that additional properties can be added without changes to Kafka.

...

Some organizations may have a requirement to use different authentication mechanisms within the same broker. For instance, this may be useful if internal and external clients connecting to the same broker use different authentication servers. Negotiation of SASL mechanisms is not included in the SASL protocol. Typically, application protocols which support multiple mechanisms include a mechanism negotiation phase where the server advertises the list of enabled mechanisms and the client selects one of the available mechanisms and sends the selected mechanism to the server. The current Kafka authentication protocol for SASL does not perform any negotiation of mechanisms since only GSSAPI is supported.

Since GSSAPI clients send a non-empty token to the broker when a connection is established, an empty packet is sent to the broker to indicate that mechanism negotiation is required. This enables new brokers to work with 0.9.0.0 clients which do not support mechanism exchange. Clients which do not specify the new configuration option sasl.mechanisms will use GSSAPI as the mechanism without negotiation to enable new clients to work with 0.9.0.0 brokers.

Client flow:

1. If sasl.mechanisms contains any mechanism other than GSSAPI, send a packet with empty payload (just the 4-byte size field set to zero) to the server. Otherwise go to Step 4 with GSSAPI as the selected mechanism.
   • Packet Format: |Empty|
2. Wait for list of SASL mechanisms from the server
3. Select a mechanism from the mechanisms enabled in the server and send the selected mechanism to the server
   • Packet Format: | Version (Int16) | Mechanism (String) |
4. Create SaslClient with the selected mechanism
5. Perform SASL authentication with the selected mechanism

Server flow:

...

• Packet Format: | Version (Int16) | EnabledMechanisms (ArrayOf(String)) |

...

To keep the Kafka protocol simple, only a single SASL mechanism is allowed for Kafka clients. For protocols other than GSSAPI, client sends the protocol name to the server before any SASL authentication packets are sent. Kafka server checks the first packet and if it is one of the mechanism names that it recognizes including custom protocol names, it switches to that mechanism and starts SASL authentication using subsequent packets. If not, the server defaults to GSSAPI mechanism, treating the first packet as the first GSSAPI authentication packet from the client.

SASL/PLAIN implementation

...

This would provide additional flexibility, but would require users to implement more code. This would be more suitable if there is a requirement to implement authentication using protocols other than SASL.

Support multiple SASL mechanisms within a Kafka broker

...

with mechanism negotiation

Typical application protocols which support multiple SASL mechanisms perform negotiation of mechanisms before commencing authentication exchange using the negotiated mechanism. This involves exchange of mechanisms followed by the chosen mechanism being sent from the client to the server. For simplicity, Kafka clients will be allowed to enable only one mechanism in the client configuration. Kafka broker chooses the mechanism based on the first packet from the client, keeping the wire protocol simple.Implementing multi-mechanism SASL as a new authentication protocol will simplify mechanism negotiation, leaving the existing protocol purely for GSSAPI. Two new security protocols SASL2_PLAINTEXT and SASL2_SSL can be added to specify the new SASL protocol that includes mechanism negotiation. But this would involve maintaining and testing two variants of SASL.

Support multiple SASL mechanisms within a Kafka broker on different ports

To avoid mechanism negotiation exchange altogether, each SASL mechanism could be defined on a different port. With the current endpoint definitions, this would require each combination of transport layer and SASL mechanism to be defined as a new security protocol. This makes it harder to introduce new mechanisms without changing Kafka code. To define custom SASL protocols, the current security protocol enumeration needs to be made extensible as well.

...