Page History

...

Kafka server and client will have a new configuration option sasl.login.class to manage the login process. This is required to plugin custom mechanisms which require login tokens to be refreshed periodically. Default login implementation will support GSSAPI and PLAIN and will be suitable for most of the standard mechanisms where mechanism-specific code can reside in the login module implementation. This interface is targeted at protocols like similar to Kerberos which require a background thread to handle token refresh.

...

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

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 , support for new mechanisms will be added using a new authentication protocol name. This will add two more security protocols SASL2_PLAINTEXT and SASL2_SSLby starting the negotiation with an empty token from the client 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.

1. Sever sends a list of enabled mechanisms to the client when a connection is established
   
   • Packet Format: | Version (Int16) | EnabledMechanisms (ArrayOf(String)) |
2. 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) |
3. Client creates SaslClient with the selected mechanism and starts SASL authentication with the selected mechanism
4. Server receives selected mechanism from client, 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

...

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

...

with GSSAPI as the SASL mechanism can be performed using a simple rolling restart with no change in properties. By default, if sasl.mechanisms property is not specified, GSSAPI will be used without any negotiation of mechanisms. If the mechanism is to be changed, this rolling restart can be followed by the addition of the new mechanism as described below.

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

...

as a new security protocol

Implementing multi-mechanism SASL as a new authentication protocol will simplify mechanism negotiation and rolling upgrade. Two new security protocols SASL2_PLAINTEXT and SASL2_SSL can be added to specify the new SASL protocol including mechanism negotiation. But this would involve maintaining and testing two variants of SASL.

To avoid mechanism negotiation 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 codeSince 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 interoperability.