[
https://issues.apache.org/jira/browse/CASSANDRA-11471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17722232#comment-17722232
]
Derek Chen-Becker edited comment on CASSANDRA-11471 at 5/12/23 4:26 PM:
------------------------------------------------------------------------
We had some discussion via Slack today and I wanted to summarize an alternative
proposal:
Instead of using a new message with AUTHENTICATE, we can leverage the OPTIONS
message that the client can send. The following changes would be required:
1. Make changes to the server so that it can be configured with more than one
supported mechanism. This will require some changes to the configuration
handling as well as some changes in the AuthN path to select the mechanism
provided by the customer in the AUTHENTICATE message
2. Make changes to the server so that it returns a new property in the
SUPPORTED message indicating a set (or list in order of preference?) of
supported AuthN mechanisms
3. Clients would need to be changed to recognize and utilize the new SUPPORTED
property
The primary benefit of leveraging OPTIONS/SUPPORTED to communicate supported
mechanisms is that it would be backwards compatible with existing clients and
would not require a change to the protocol messages. Additionally, change #1
would allow clients that don't use the OPTIONS message to still benefit from
being able to transition between AuthN mechanisms.
was (Author: dchenbecker):
We had some discussion via Slack today and I wanted to summarize an alternative
proposal:
Instead of using a new message with AUTHENTICATE, we can leverage the OPTIONS
message that the client can send. The following changes would be required:
1. Make changes to the server so that it can be configured with more than one
supported mechanism. This will require some changes to the configuration
handling as well as some changes in the AuthN path to select the mechanism
provided by the customer in the AUTHENTICATE message
2. Make changes to the server so that it returns a new property in the
SUPPORTED message indicating a set (or list in order of preference?) of
supported AuthN mechanisms
3. Clients would need to be changed to recognize and utilize the new SUPPORTED
property
The primary benefit of leveraging OPTIONS/SUPPORTED to communicate supported
mechanisms is that it would be backwards compatible with existing clients and
would not require a change to the protocol messages.
> 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: Legacy/CQL
> Reporter: Sam Tunnicliffe
> Assignee: Ben Bromhead
> Priority: Normal
> Fix For: 5.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
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
