Hi Kafka Team,
As a practical test-case of KIP-35, I'd like to turn your attention to
KIP-43:
https://cwiki.apache.org/confluence/display/KAFKA/KIP-43
KIP-43 makes an interesting modification to the protocol, but only under
specific conditions:
"*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: | 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."
I'd love to know how this will be communicated to clients via
VersionRequest proposed in KIP-35 (mostly because Jun and I need to review
KIP-43 and we want to be sure we are not breaking the new protocol at the
same time we introduce it)
Do we:
1. Bump protocol version of every single Request? Even though unless you
are using a new sasl mechanism nothing changes?
2. Ignore and not bump protocol? If so, how will clients know that new
sasl.mechanisms are supported?
3. Something else?
Gwen
