Page History

...

1. sasl.mechanism (List<String>) Specifies the list of SASL mechanisms that are enabled. This may include any mechanism for which a security provider is available in the JVM. Default value is GSSAPI.
2. sasl.callback.handler.class  (Class). The fully qualified name of a class that implements the AuthCallbackHandler interface. This class should have a default constructor and implement the callback handlers required for the configured mechanismmechanisms. Default implementation supports callback handlers for GSSAPI and PLAIN.
3. sasl.login.class  (Class). The fully qualified name of a class that implements the Login interface. This class should have a default constructor.

...

package org.apache.kafka.common.security.auth;
import java.util.Map;
import javax.security.auth.Subject;
import javax.security.auth.login.LoginContext;
import javax.security.auth.login.LoginException;
/**
 * Login interface for authentication
 */
public interface Login {    
    /**
     * Configures this login instance.
     */
    void configure(Map<String, ?> configs, String loginContextName);
    /**
     * Performs login for each login module specified for the login context of this instance.
     */
    LoginContext login() throws LoginException;    
    /**
     * Returns the authenticated subject of this login context.
     */
    Subject subject();    
    /**
     * Returns the service name to be used for Sas
     */
    String serviceName();
    /**
     * Closes this instance.
     */
    void close();
}

...

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 will be initiated by the client to enable support for multiple mechanisms within a broker without impacting existing 0.9.0.0 clients which use the default GSSAPI mechanism without negotiation.

...

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)

1. 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|
2. 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)) |
3. 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) |
4. Client creates SaslClient with the selected mechanism and starts SASL authentication with the selected mechanism
5. Server receives selected mechanism from client
6. Server 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.Mechanism negotiation will be initiated by the client with a packet with empty payload. This avoids conflict with existing 0.9.0.0 clients which send the first non-empty client token for GSSAPI without mechanism negotiation. This ensures interoperability between 0.9.0.0 clients or broker with the updated protocol.

Rolling upgrade with change in SASL mechanism

...