Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  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

This KIP does not address:

  1. Support for multiple SASL mechanisms within a broker. This would require multiple login contexts to support each mechanism and a means of choosing the mechanism for authentication in the server. It would be better to address this in another KIP if there is a requirement.

Public Interfaces

Configuration options

...

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

Typically SASL implementations negotiate SASL mechanism before the SASL authentication exchange. The server sends a list of mechanisms that it supports to the client when a connection is established and the client chooses one of those mechanisms that satisfies its requirements. The current wire protocol used by Kafka for SASL does not support negotiation of mechanisms. Since the flow that follows transport-layer handshake is mechanism-specific data and there is currently no versioning of authentication flows, introduction of mechanism negotiation will be a breaking change. If we anticipate that multi-mechanism support may be required in future, it may be better to include it now since it might be possible to design a flow that doesn't conflict with the current GSSAPI flow, enabling the choosing of mechanisms without breaking existing clients. The changes required to support this are

  1. Change sasl.mechanism to List<String> instead of single String
  2. Add a new flow for choosing mechanisms
  3. Peek into the initial client SASL response to determine if it is an old style-client sending a GSSAPI packet or a new style client sending the negotiated mechanism
  4. Create SaslServer with the negotiated mechanism
  5. A single login context with multiple login modules with be used for the JAAS configuration. Adjust default callbacks if necessary to work with multiple login modules.