kafka-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From rsiva...@apache.org
Subject [kafka] branch 1.1 updated: MINOR: Updated SASL Authentication Sequence Docs (#4724)
Date Tue, 20 Mar 2018 13:59:00 GMT
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 <mimaison@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 <ecomar@uk.ibm.com>, Mickael Maison <mickael.maison@gmail.com>
    
    Reviewers: Rajini Sivaram <rajinisivaram@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.

Mime
View raw message