Versions Compared

Old Version 5

changes.mady.by.user Rajini Sivaram

Saved on

compared with

New Version 6

changes.mady.by.user Rajini Sivaram

Saved on

Key

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

...

SaslHandshake request version will be bumped up from v0 to v1, without any change to the request or response format. For compatibility between 0.10/0.x 11 clients and 1.0.11.x 0 brokers, the new SaslAuthenticate requests will be used only if SaslHandshake v1 is used to initiate handshake.
A new error code AUTHENTICATION_FAILED will be added along with a corresponding AuthenticationFailedException.
1.0.11.0 Java clients will send an ApiVersions request prior to sending SaslHandshake request and use SaslHandshake v1 only if supported by the broker. Otherwise, the older format authentication will be used, enabling 1.0.11.0 clients to authenticate with 0.10/0.x 11  brokers. 1.0.11.x 0 brokers will expect older format authentication unless SaslHandshake v1 is used to initiate the handshake, maintaining compatibility with older clients.

...

  • ApiVersions request is sent by the client to determine SaslHandshake version prior to authentication. This is supported by 0.10/ 0.x 11 brokers, retaining compatibility between 1.0.11.x 0 clients and 0.10.x older brokers. Since 0.10/0.x 11 brokers treat schema exceptions in the first request as GSSAPI auth message for compatibility with 0.9.x clients, ApiVersions v0 request will be used. As no throttling is performed prior to authentication, v0 is sufficient for the initial request.
  • If SaslHandshake version is v0, then the older wire format is used for authentication. SASL authentication messages are sent as length-encoded byte arrays without wrapping the messages with Kafka protocol headers.
  • If SaslHandshake version is v1, clients will send SASL authentication messages using the new SaslAuthenticate request/response format, where the actual SASL authentication message blobs are wrapped in the Kafka protocol. The network layer code for SASL already does creation and parsing of Kafka protocol requests and responses to process SaslHandshake request, so this will be a straightforward change.
  • The final message from the broker will indicate if authentication succeeded or failed. Successful authentications will be logged at debug level. Failed authentications will be logged as warnings.

Authentication error handling

  • If authentication fails, broker will return an error response and then close the connection.
  • Java clients will log a warning for authentication failures, distinguishing these from EOF exceptions due to connection failure.
  • Nodes to which connection failed due to authentication failure will be blacked out for the reconnect backoff interval.
  • Producer waitForMetadata and consumer ensureCoordinatorReady will be updated to throw AuthenticationFailedException if connection to a broker fails authentication.

...

The wire-protocol changes from this KIP will be used only if SaslAuthenticate requests are supported by both the broker and the client. So existing clients and brokers will not be impacted.

0.9.x client => 1.0.11.0 broker

0.9.x clients start GSSAPI authentication straight after TLS handshake. 0.9.x clients connecting to 1.0.11.0 brokers will be handled by treating the first message as a GSSAPI auth message if it is not an ApiVersions or SaslHandshake request. This is already supported in the broker.

0.10.x, 0.11.0 client => 1.0.11.0 broker

0.10.x and 0.11.0 clients send SaslHandshake v0 request as the first message. 1.0.11.0 brokers will use the current length-encoded SASL authentication message blobs that are not wrapped with Kafka request/response headers when v0 handshake request is used.

1.0.11.0 client => 0.10.x, 0.11.0 broker

1.0.11.0 clients connecting to 0.10/0.x 11 brokers will send an ApiVersions request to determine if SaslHandshake v1 is supported. 0.10.x brokers already respond to versions request prior to SASL handshake. We will use ApiVersions v0 for the initial request prior to handshake since no throttling is performed prior to authentication. 1.0.11.0 clients will use SaslHandshake v0 to authenticate with 0.10.x and 0.11.0 brokers using the current length-encoded SASL authentication messages that are not wrapped with Kafka request/response headers.

...