Page History

...

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 the list of enabled mechanisms to the client and the client selects one of the available mechanisms and responds to the server. The current Kafka authentication protocol for SASL does not perform any negotiation of mechanisms since only GSSAPI is supported. To enable negotiation of mechanisms without breaking existing 0.9.0.0 clients, the following flow will be used: (TODO: this is work in progress)support for new mechanisms will be added using a new authentication protocol name. This will add two more security protocols SASL2_PLAINTEXT and SASL2_SSL.

1. Sever sends a list of enabled mechanisms to the client when a connection is established
2. Client sends a packet with empty payload (4-byte size set to zero). This avoids conflict with existing 0.9.0.0 clients which send the first non-empty client token for GSSAPI without mechanism negotiation.
   • Packet Format: |EMPTY|
3. Server responds with enabled mechanisms on seeing the empty packet. If the first packet is non-empty, server assumes GSSAPI protocol and omits the mechanism negotiation phase (0.9.0.0 client starts at Step 4, server moves to Step 6 with the first client token to process)
   
   • Packet Format: | Version (Int16) | EnabledMechanisms (ArrayOf(String)) |
4. Client chooses a mechanism from the mechanisms enabled in the server and sends the selected mechanism to the server
   • Packet Format: | Version (Int16) | Mechanism (String) |
5. Client creates SaslClient with the selected mechanism and starts SASL authentication with the selected mechanism
6. Server receives selected mechanism from clientServer , creates SaslServer with the selected mechanism and starts SASL authentication

...

Existing clients will continue to use GSSAPI as the SASL mechanism and will not be impacted by the changes. Since default callback handlers can be used for SASL mechanisms that are implemented in Kafka, no configuration changes are required.

Rolling upgrade from 0.9.0.0 to enable new mechanisms

Rolling upgrade from 0.9.0.0 using the following sequence can be used to enable new SASL mechanisms:

1. Enable the new SASL2_PLAINTEXT/SASL2_SSL protocol in the broker using rolling restart with change in configuration properties required for the new mechanism(s)
2. Restart all clients with new security protocol
3. Disable the old SASL protocol in the broker

Rolling upgrade with change in SASL mechanism

...

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

...

without changing protocol names

Since 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 to indicate that mechanism negotiation is required. But to support the reverse scenario of supporting new clients with the 0.9.0.0 broker, the clients need to know that the broker is of an older version and avoid the negotiation phase. Alternatively, we need to introduce partial support in 0.9.0.1 to handle the initial empty packet from the client to enable migration from 0.9.0.0->0.9.0.1->0.9.1 to enable full interoperabilityThis would require different SASL mechanisms to be defined as different security protocols to work with the current endpoint definitions. While this approach avoids the protocol changes required for negotiation of mechanisms, it makes it harder to add new mechanisms with every combination of transport layer protocol and SASL mechanism turning into a new security protocol. Negotiation of mechanisms makes the code slightly more complex, but provides a neater and more flexible external interface which is consistent with the way mechanisms are chosen in other SASL-enabled protocols.