...

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

Public Interfaces

Configuration options

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

1. sasl.mechanismmechanisms (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 mechanisms. 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.

...

1. LoginContext that specifies the login module class and properties for the login module, specified using JAAS configuration
2. SASL mechanism and other properties specific to the mechanism configured as Kafka client or server properties. Additional properties and selection policies handled by the SASL implementation may also be specified when the SaslClient or SaslServer is constructed.
3. Additional input required by the SASL implementation obtained using CallbackHandlers
   
4. SaslServer or SaslClient implementation for the configured mechanism. These are installed as security providers in the JVM. For custom mechanisms, providers can be initialized in the static initializer of the login module to ensure that the providers are installed before Kafka creates the SaslServer/SaslClient.

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.

...

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 specified as String options rather than an enum with a restricted set of values.  GSSAPI will be used as the default mechanism without mechanism negotiation for interoperability of new clients with 0.9.0.0 brokers. If a list of mechanisms is specified, a mechanism is selected by the client after exchange of mechanisms supported in the server, as described later.

...

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 similar to Kerberos which require a background thread to handle token ticket refresh.

Support for multiple mechanisms in a broker

...

Since GSSAPI clients send a non-empty token to the broker when a connection is established, an empty packet is sent to the broker to indicate that mechanism negotiation is required. This enables new brokers to work with 0.9.0.0 clients which do not support mechanism exchange. 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. 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 selected mechanism from client
5. Create SaslServer with the selected mechanism
6. Perform SASL authentication. If mechanism negotiation was skipped, process the initial packet that was received from the client first.

SASL/PLAIN implementation

...