[kafka] branch trunk updated: MINOR: Updated SASL Authentication Sequence Docs (#4724)

[rs...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

rsivaram pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/kafka.git


The following commit(s) were added to refs/heads/trunk by this push:
     new 36d4b91  MINOR: Updated SASL Authentication Sequence Docs (#4724)
36d4b91 is described below

commit 36d4b91573028a687236ab27154ce4a04d9d8cb3
Author: Mickael Maison <mi...@users.noreply.github.com>
AuthorDate: Tue Mar 20 13:56:40 2018 +0000

    MINOR: Updated SASL Authentication Sequence Docs (#4724)
    
    Reworded the SASL Authentication sequence to update it to >= 1.0.0
    
    Co-authored-by: Edoardo Comar <ec...@uk.ibm.com>, Mickael Maison <mi...@gmail.com>
    
    Reviewers: Rajini Sivaram <ra...@googlemail.com>
---
 docs/protocol.html | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/docs/protocol.html b/docs/protocol.html
index 85f4133..0daa3b8 100644
--- a/docs/protocol.html
+++ b/docs/protocol.html
@@ -148,10 +148,11 @@
   <li>Kafka <code>ApiVersionsRequest</code> may be sent by the client to obtain the version ranges of requests supported by the broker. This is optional.</li>
   <li>Kafka <code>SaslHandshakeRequest</code> containing the SASL mechanism for authentication is sent by the client. If the requested mechanism is not enabled
     in the server, the server responds with the list of supported mechanisms and closes the client connection. If the mechanism is enabled
-    in the server, the server sends a successful response and continues with SASL authentication.
-  <li>The actual SASL authentication is now performed. A series of SASL client and server tokens corresponding to the mechanism are sent as opaque
-    packets. These packets contain a 32-bit size followed by the token as defined by the protocol for the SASL mechanism.
-  <li>If authentication succeeds, subsequent packets are handled as Kafka API requests. Otherwise, the client connection is closed.
+    in the server, the server sends a successful response and continues with SASL authentication.</li>
+  <li>The actual SASL authentication is now performed. If <code>SaslHandshakeRequest</code> version is v0, a series of SASL client and server tokens corresponding to the mechanism are sent
+     as opaque packets without wrapping the messages with Kafka protocol headers. If <code>SaslHandshakeRequest</code> version is v1, the <code>SaslAuthenticate</code>
+     request/response are used, where the actual SASL tokens are wrapped in the Kafka protocol. The error code in the final message from the broker will indicate if authentication succeeded or failed.</li>
+  <li>If authentication succeeds, subsequent packets are handled as Kafka API requests. Otherwise, the client connection is closed.</li>
 </ol>
 <p>For interoperability with 0.9.0.x clients, the first packet received by the server is handled as a SASL/GSSAPI client token if it is not a valid
 Kafka request. SASL/GSSAPI authentication is performed starting with this packet, skipping the first two steps above.</p>

-- 
To stop receiving notification emails like this one, please contact
rsivaram@apache.org.