cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ariel Weisberg (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-11471) Add SASL mechanism negotiation to the native protocol
Date Mon, 03 Apr 2017 20:21:41 GMT


Ariel Weisberg commented on CASSANDRA-11471:

I don't have any objections to using Optional and I don't think there is a codified objection
to it in the project. For this use case it's fine. I would just keep optional allocations
out of any per request, or per row or column loops and avoid them for frequently used lookups.
I think it's fine to use them when accepting a connection.

I guess what is confusing me here is that all the tests passed when the new startup message
was being sent to the v4 client that is checked in and used for the tests. I can't tell if
I check this in, will it break things since the v5-beta driver doesn't understand the new
SASL mechanism? It seems like things should have not worked, but then they did.

The dtests use cassandra-test branch of the python driver which claims v5 support. The checked
in Python and Java driver both don't claim v5 support so those should continue to work even
if we commit this change without doing the driver work.

Wha I am afraid of is checking this in and breaking the dtests. CassCI is no longer available
so right now I don't have a great way to run the tests.

> 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
>             Fix For: 4.x
>         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