cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ben Bromhead (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-11471) Add SASL mechanism negotiation to the native protocol
Date Fri, 24 Mar 2017 20:05:41 GMT


Ben Bromhead commented on CASSANDRA-11471:

Addressed all the comments except one.

bq. Only if encryption is optional? Basically because the authenticator can only work if the
certificates are there? It seems like this can NPE?

Currently getSaslNegotiator will try to get the certificate chain from the channel if client
encryption is enabled and connecting on an encrypted session is not optional. 

This means null instead of a certificate chain will be passed in when getting the new SASL
authenticator. I couldn't think of a nice way to pass the certificate chain to the authenticator
but still respect the fact there are authenticators that just don't care about them. 

Given that Optional does not appear to be used in the project and I didn't want to add even
more more methods to IAuthenticator. Thinking about it again, it probably just makes sense
to overload newV5SaslNegotiator and not have to pass in certificates, which would reduce the
chance of someone implementing a new Authenticator getting an NPE.


> Add SASL mechanism negotiation to the native protocol
> -----------------------------------------------------
>                 Key: CASSANDRA-11471
>                 URL:
>             Project: Cassandra
>          Issue Type: Sub-task
>          Components: CQL
>            Reporter: Sam Tunnicliffe
>            Assignee: Ben Bromhead
>              Labels: client-impacting
>         Attachments: CASSANDRA-11471
> Introducing an additional message exchange into the authentication sequence would allow
us to support multiple authentication schemes and [negotiation of SASL mechanisms|].

> The current {{AUTHENTICATE}} message sent from Client to Server includes the java classname
of the configured {{IAuthenticator}}. This could be superceded by a new message which lists
the SASL mechanisms supported by the server. The client would then respond with a new message
which indicates it's choice of mechanism.  This would allow the server to support multiple
mechanisms, for example enabling both {{PLAIN}} for username/password authentication and {{EXTERNAL}}
for a mechanism for extracting credentials from SSL certificates\* (see the example in [RFC-4422|]).
Furthermore, the server could tailor the list of supported mechanisms on a per-connection
basis, e.g. only offering certificate based auth to encrypted clients. 
> The client's response should include the selected mechanism and any initial response
data. This is mechanism-specific; the {{PLAIN}} mechanism consists of a single round in which
the client sends encoded credentials as the initial response data and the server response
indicates either success or failure with no futher challenges required.
> From a protocol perspective, after the mechanism negotiation the exchange would continue
as in protocol v4, with one or more rounds of {{AUTH_CHALLENGE}} and {{AUTH_RESPONSE}} messages,
terminated by an {{AUTH_SUCCESS}} sent from Server to Client upon successful authentication
or an {{ERROR}} on auth failure. 
> XMPP performs mechanism negotiation in this way, [RFC-3920|]
includes a good overview.
> \* Note: this would require some a priori agreement between client and server over the
implementation of the {{EXTERNAL}} mechanism.

This message was sent by Atlassian JIRA

View raw message