[
https://issues.apache.org/jira/browse/CASSANDRA-11471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15971384#comment-15971384
]
Adam Holmberg commented on CASSANDRA-11471:
-------------------------------------------
bq. 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?
This has come up a number of times with new contributors driving
client-impacting changes. There is not an official policy on this, but it
probably warrants writing down somewhere. For now I will quote a [previous
comment|https://issues.apache.org/jira/browse/CASSANDRA-13304?focusedCommentId=15907797&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15907797]:
{quote}
I don't think there is a policy defined, but I can describe what I've observed
in the past:
- Tickets requiring driver updates are labeled `client-impacting` on creation
- Devs or reviewers ping driver maintainers to make sure they're aware (early
in design/impl is best)
- Tickets get created in the driver JIRAs, and stakeholders coordinate on when
it will be addressed
- If the server ticket gets ahead of driver scheduling, and the feature
requires client integration tests, the contributor will sometimes implement the
feature in one of the drivers, and offer a PR
- The server ticket can either block pending driver releases, or take the
feature and package a snapshot of the driver (understanding that the driver
maintainers reserve the right to change API and functionality before final
merge). How this is managed depends on where the projects are relative to their
own major milestones, and the risk and impact of change.
{quote}
I created
[CASSANDRA-13453|https://issues.apache.org/jira/browse/CASSANDRA-13453] to
write this up somewhere.
> 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)
