[
https://issues.apache.org/jira/browse/CASSANDRA-11471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15969643#comment-15969643
]
Ben Bromhead commented on CASSANDRA-11471:
------------------------------------------
So I had a look at the cassandra-test branch for the python driver. Default
highest supported protocol is v4
(https://github.com/datastax/python-driver/blob/cassandra-test/cassandra/cluster.py#L358)
which means it should have hit the new code path (e.g. it received a list of
SASL mechanisms instead of the JAVA class).
The thing is the the python PasswordAuthenticator code doesn't actually care
about the first server challenge, it just sends the username and password
irrespective of what the server says as part of the startup message. In
connection.py I can't see where the authenticator_class ever gets used (it does
however get assigned).
Which would go someway to explaining why it worked.
In the meantime I've updated my branch to use optional.
It might make sense to land support for SASL negotiation in the python driver
first before committing this, however like any protocol change both C* and the
driver the tests depend on will need to change simultaneously with tests
potentially breaking in between? Unless there is a process around this?
> Add SASL mechanism negotiation to the native protocol
> -----------------------------------------------------
>
> Key: CASSANDRA-11471
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11471
> 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|https://tools.ietf.org/html/rfc4422#section-3.2].
> 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|https://tools.ietf.org/html/rfc4422#appendix-A]). 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|http://tools.ietf.org/html/rfc3920#section-6] 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
(v6.3.15#6346)
