THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
ApiVersionsrequest is sent by the client to determineSaslHandshakeversion prior to authentication. This is supported by 0.10.x brokers, retaining compatibility between 0.11.x clients and 0.10.x brokers. Since 0.10.x brokers treat schema exceptions in the first request as GSSAPI auth requests message for compatibility with 0.9.x clients,ApiVersionsv0request will be used. As no throttling is performed prior to authentication,v0is sufficient for the initial request.- If
SaslHandshakeversion isv0, 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
SaslHandshakeversion isv1, clients will send SASL authentication messages using the newSaslAuthenticaterequest/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 processSaslHandshakerequest, 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, no more attempts will be made to connect to these nodes.
- Producer
waitForMetadataand consumerensureCoordinatorReadywill be updated to throwAuthenticationFailedExceptionif connections to all available brokers fail authentication.
...
What impact (if any) will there be on existing users?
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 clients start GSSAPI authentication straight after TLS handshake. 0.9.x clients connecting to 0.11.0 brokers will be handled by treating the first message as a GSSAPI auth message if it is not an ApiVersionsRequest ApiVersions or SaslHandshakeRequest SaslHandshake request. This is already supported in the broker.
...
0.11.0 clients connecting to 0.10.x brokers will send an ApiVersionsRequest ApiVersions request to determine if SaslHandshake v1 is supported. 0.10.x brokers already respond to versions request prior to Sasl SASL handshake. We will use ApiVersions v0 for the initial request prior to hanshake handshake since no throttling is performed prior to authentication. 0.11.0 clients will use SaslHandshake v0 to authenticate with 0.10.x brokers using the current length-encoded SASL authentication messages that are not wrapped with Kafka request/response headers.
...
We will continue to support the older behavior. There is no plan to remove support for the current SaslHandshake v0 request combined with the current length-encoded authentication message blobs at the moment. We will also continue to support the older 0.9.x GSSAPI clients which don't send handshake requests.
Rejected Alternatives
Send an error code if SASL authentication fails
We could retain the existing wire protocol for SASL authentication and add an authentication error code that is sent by the broker if SASL authentication fails, just before closing the connection. This will be treated as an invalid token by the SASL client authenticator, and the error handling for invalid tokens can be updated to report authentication failure for this case. This is a bit of a hack, but would work with GSSAPI, PLAIN and SCRAM. The PR for KAFKA-4764 currently implements this and has been tested with all the mechanisms in Kafka. The current proposal in this KIP is a bigger change, but is future-proof.
...
Add just an error code to SASL authentication messages from the broker without adding the entire Kafka request/response header.
Most of the fields in the headers like client-id are irrelevant for SASL messages which are treated as a blob by Kafka. Hence it may be unnecessary to add the entire header. Just a status/error code would be sufficient. Kafka request format was chosen since we already use this format for SaslHandshake requests, so the authenticators already create and parse have knowledge of Kafka requests. Also, this enables the API to evolve in future if required.
...