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 a list of String options rather than an enum with a restricted set of values.  Mechanism negotiation GSSAPI will be initiated by the client to enable support for multiple mechanisms within a broker without impacting existing used as the default mechanism without mechanism negotiation for interoperability of new clients with 0.9.0.0 clients which use the default GSSAPI mechanism without negotiationbrokers. If mechanisms are specified, one is selected by the client after exchange of supported mechanisms, as described later.

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.

...

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 within the SASL protocol. Typically, application protocols which support multiple mechanisms include a mechanism negotiation phase where the server sends advertises the list of enabled mechanisms to the client and the client selects one of the available mechanisms and responds sends the 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, it would be possible to support mechanism negotiation in the broker without breaking existing 0.9.0.0 clients by starting the negotiation with an empty token from the client an empty packet is sent to the broker to indicate that mechanism negotiation is required. 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 is specified as a non-empty list, 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.Sever sends a list of enabled mechanisms to the client when a connection is established
   • Packet Format: | Version (Int16) | EnabledMechanisms (ArrayOf(String)) |Empty|
2. Wait for list of SASL mechanisms from the server
3. Select Client chooses a mechanism from the mechanisms enabled in the server and sends send the selected mechanism to the server
   • Packet Format: | Version (Int16) | Mechanism (String) |
4. Client creates Create SaslClient with the selected mechanism and starts
5. Perform SASL authentication with the selected mechanism

Server flow:

1. Wait for first authentication packet from client
2. If client payload size is not zero, skip mechanism negotiation and go to Step 5 and process this packet as the first GSSAPI client token
3. Send a list of enabled mechanisms to the client
   
   • Packet Format: | Version (Int16) | EnabledMechanisms (ArrayOf(String)) |
4. Wait for receives selected mechanism from client
5. Create , creates SaslServer with the selected mechanism and starts
6. Perform SASL authentication. If mechanism negotiation was skipped, process the initial packet that was received from the client
   
   

SASL/PLAIN implementation

...