[kafka] branch 1.1 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 1.1
in repository https://gitbox.apache.org/repos/asf/kafka.git


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

commit a101de996413c3784b7a3d2e90c90b5e132b4d3a
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 4042223..6e45b5e 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.