[ https://issues.apache.org/jira/browse/CASSANDRA-11471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15943625#comment-15943625 ]
Ariel Weisberg commented on CASSANDRA-11471: -------------------------------------------- Congrats on thew new baby! If your back this soon I'll take it as a good sign. * [Typo in associated|https://github.com/apache/cassandra/compare/trunk...benbromhead:11471#diff-f4a806982d4fb565a8ceb5476cfb5978R64] * [Should this be <= since we are going to change the v5-beta protocol?|https://github.com/apache/cassandra/compare/trunk...benbromhead:11471#diff-a6c0d16b6f8e72454c376efc0adf51f9R103] So I am generally speaking OK with the code modulo the nit and the question. Kicked off the tests just to see what happens with the Java driver part not done. I asked in #datastax-drivers IRC about how we land a change to the v5-beta version of the protocol. ||Code|utests|dtests|| |[trunk|https://github.com/benbromhead/cassandra/compare/trunk...aweisberg:cassandra-11471-trunk?expand=1]|[utests|https://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-cassandra-11471-trunk-testall/1/]|[dtests|https://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-cassandra-11471-trunk-dtest/1/]| > 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)