Page History

...

JIRA:

Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).

...

1. Configurable SASL implementation to enable integration with existing authentication servers
2. Support for additional SASL mechanisms. This enables standard mechanisms that do not have a default implementation in Kafka (eg. DIGEST-MD5) as well as custom mechanisms
3. Configurable callback handlers to provide mechanism-specific input
4. SASL/PLAIN implementation to enable simple username/password authentication without complex infrastructure
5. Support for multiple SASL mechanisms within the same client or server. This will be useful, for example, in organizations where internal and external users require different authentication mechanisms.
6. Configurable login interface that manages the login process and the lifecyle of login context related resources to support custom mechanisms that require periodic ticket refresh

...

The following options will be added to SaslConfigs.java and can be configured as properties for Kafka clients and server:

1. sasl.mechanism (String) SASL mechanism used for client connections. This may be any mechanism for which a security provider is available in the JVM. Default value is GSSAPI.
2. sasl.enabled.mechanisms (List<String>) Specifies the The list of SASL mechanisms that are enabled in the Kafka server. This may include any mechanism for which a security provider is available in the JVM. Default value is GSSAPI.
3. 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 mechanisms. Default implementation supports callback handlers for GSSAPI and PLAIN.
4. 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 org.apache.kafka.common.annotation.InterfaceStability;
import org.apache.kafka.common.network.Mode;
import org.apache.kafka.common.KafkaException;
import javax.security.auth.callback.CallbackHandler;
/*
 * Callback handler for SASL-based authentication
 */
@InterfaceStability.Unstable
public interface AuthCallbackHandler extends CallbackHandler {
    
    /**
     * Configures this callback handler.
     * 
     * @param configs Configuration
     * @param mode The mode that indicates if this is a client or server connection
     * @param subject Subject from login context
     * @param saslMechanism Negotiated SASL mechanism
     */
    void configure(Map<String, ?> configs, Mode mode, Subject subject, String saslMechanism) throws KafkaException;
    /**
     * Closes this instance.
     */
    void close() throws KafkaException;
}

...

The changes will be implemented under two JIRAs. KAFKA-3149 implements the . The implementation will include changes to support additional mechanisms and enable new multiple mechanisms . KAFKA-2658 will be rebased after the review of this KIP to include a in the broker. A simple default implementation for SASL/PLAIN in Kafka that is currently in KAFKA-2658 will also be included. This section gives a summary of the changes and the rationale behind them.

...

All the four types of configuration above need to be configured consistently for SASL authentication to operate correctly. 1) and 4) are JVM configuration options. 2) and 3) are currently hard-coded in Kafka. The proposed changes enable flexible configuration for 2) and 3) to enable any SASL mechanism to be supported in Kafka clients and servers.

SASL mechanism

Kafka server and client will have a new Client connections will use the property sasl.mechanism to specify the mechanism to be used for SASL authentication. Kafka servers may also specify the configuration option sasl.enabled.mechanisms to specify provide the list of enabled mechanisms when multiple mechanisms are enabled in the server. In order to plug in any SASL mechanism including custom mechanisms, mechanisms mechanism will be specified as String rather than an enum with a restricted set of values.  GSSAPI will be used as the default mechanism for interoperability of new clients with 0.9.0.0 brokers. Clients 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 mechanismsfails the authentication if the client mechanism is not enabled in the broker.

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.

...

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.

Client flow:

1. If sasl.mechanism is not GSSAPI, send a packet with the mechanism name to the server. Otherwise go to Step 3.
   • Packet Format: | Version (Int16) | Mechanism (String) |
2. Wait for response from the server. If the error code in the response is non-zero, indicating failure, report the error and fail authentication.
3. Perform SASL authentication with the configured client mechanism

Server flow:

1. Wait for first authentication packet from client
2. If this packet is a not valid mechanism request, go to Step 4 and process this packet as the first GSSAPI client token
3. If the client mechanism received in Step 2 is enabled in the broker, send a response with error code zero and start authentication using the specified mechanism. Otherwise, send an error response including the list of enabled mechanisms and fail authentication.
   
   • Packet Format: | Version (Int16) | ErrorCode (Int16)| EnabledMechanisms (ArrayOf(String)) |
4. Perform SASL authentication with the selected mechanism. If mechanism exchange was skipped, process the initial packet that was received from the client first.

SASL/PLAIN implementation

...

Rolling upgrade with GSSAPI as the SASL mechanism can be performed using a simple rolling restart with no change in properties. By default, if sasl.mechanismsmechanism property is not specified, GSSAPI will be used without any negotiation exchange 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.

...