[
https://issues.apache.org/jira/browse/KAFKA-4764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15998186#comment-15998186
]
Rajini Sivaram commented on KAFKA-4764:
---------------------------------------
[~junrao] SASL was designed to be embedded into a protocol like LDAP. And Kafka
is one such protocol, but we (like ZooKeeper) chose a slightly different way of
integrating with SASL from the way it was designed to be used. According to the
[SASL RFC|https://tools.ietf.org/html/rfc4422],
{quote}
To use SASL, each protocol (amongst other items) provides a method for
identifying which mechanism is to be used, a method for exchange of
mechanism-specific server-challenges and client-responses, and a method for
communicating the outcome of the authentication exchange.
{quote}
We have the {{SaslHandshake}} request to identify the mechanism. And we have
the code to exchange challenges and responses. But we don't have a method for
communicating the outcome.
[SASL/PLAIN RFC|https://tools.ietf.org/html/rfc4616] has examples using ACAP:
{quote}
S: * ACAP (SASL "CRAM-MD5") (STARTTLS)
C: a001 STARTTLS
S: a001 OK "Begin TLS negotiation now"
<TLS negotiation, further commands are under TLS layer>
S: * ACAP (SASL "CRAM-MD5" "PLAIN")
C: a002 AUTHENTICATE "PLAIN"
S: + ""
C: (21)
C: <NUL>tim<NUL>tanstaaftanstaaf
S: a002 OK "Authenticated"
{quote}
Here client message a002 starts the PLAIN authentication. Authentication
messages are sent and received in the next three lines. The outcome, i.e.
response to request a002 is sent after the authentication completes or fails.
In Kafka, it feels like it would be easier to add a header to the SASL
exchanges with the final message containing the outcome from the broker, rather
than have a Kafka protocol request followed by non-Kafka SASL messages followed
by Kafka protocol response.
Obviously, this is just based on my reading of the RFCs. It will also be useful
if you or [~ijuma] have a look too to make sure I haven't missed anything,
before deciding whether this is the right approach.
Thank you...
> Improve diagnostics for SASL authentication failures
> ----------------------------------------------------
>
> Key: KAFKA-4764
> URL: https://issues.apache.org/jira/browse/KAFKA-4764
> Project: Kafka
> Issue Type: Improvement
> Components: security
> Affects Versions: 0.10.2.0
> Reporter: Rajini Sivaram
> Assignee: Rajini Sivaram
> Fix For: 0.11.0.0
>
>
> At the moment, broker closes the client connection if SASL authentication
> fails. Clients see this as a connection failure and do not get any feedback
> for the reason why the connection was closed. Producers and consumers retry,
> attempting to create successful connections, treating authentication failures
> as transient failures. There are no log entries on the client-side which
> indicate that any of these connection failures were due to authentication
> failure.
> This JIRA will aim to improve diagnosis of authentication failures with the
> following changes:
> - Broker will send an authentication error code if SASL authentication fails,
> just before closing the connection. This will be treated as an invalid token
> by the client authenticator, and the error handling for invalid tokens will
> be updated to report authentication failure for this case. This is a bit of a
> hack, but would work with GSSAPI, PLAIN and SCRAM. SASL itself doesn't
> provide a mechanism-independent way of reporting authentication failures. An
> alternative would be to wrap SASL authentication in Kafka request/response to
> enables error codes to be sent as Kafka response, but that would be a much
> bigger change.
> - Log a warning in clients for authentication failures, distinguishing these
> from EOF exceptions due to connection failure
> - Blackout nodes to which connection failed due to authentication error, no
> more attempts will be made to connect to these nodes.
> - We should use the connection state to improve handling of producer/consumer
> requests, avoiding unnecessary blocking. This will not be addressed in this
> JIRA, KAFKA-3899 should be able to use the additional state from JIRA to fix
> this issue.
> This JIRA also does not change handling of SSL authentication failures.
> javax.net.debug provides sufficient diagnostics for this case, I don't
> believe there is sufficient information in `SslTransportLayer` to treat these
> in a consistent way with SASL authentication failures.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
