[
https://issues.apache.org/jira/browse/CASSANDRA-11471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16000796#comment-16000796
]
Sam Tunnicliffe commented on CASSANDRA-11471:
---------------------------------------------
Sorry I'm a bit late to the party, and further apologies that I've not had
chance to dig too deeply into this yet, but I have a couple of comments on the
proposed implementation:
* The original intent of this ticket was to enable multiple mechanisms to be
supported simultaneously (e.g. use common name auth for encrypted connections
if the certificates would allow it and fall back to password auth if not), but
the patch as it is doesn't exactly do that. It seems to me that an admin could
provide a custom {{IAuthenticator}} which had a list of mechanisms > 1 but it
feels like that doesn't really improve on the status quo that much. Ideally, I
think we need to be able to configure multiple {{IAuthenticators}} in yaml and
have the client choose which of them to interact with. There are a few places
which make an assumption that there is only a single {{IAuthenticator}}, so
those would need to be addressed.
* Following from that, I don't think that negotiation of the actual mechanism
ought to be a function of the {{SASLNegotiator}} itself, at least not in it's
current form ({{NegotiatingSaslNegotiator}}). Maybe we can compose the
available/supported {{IAuthenticators}} into some class which aggregates them &
have it perform the negotiation (i.e. selecting the instance based on the
client's chosen mechanism). Or maybe this just happens in
{{AuthResponse::execute}}. Basically, the actual {{IAuthenticator}} doesn't
need to get involved until its mechanism has been selected.
* Rather than adding a new factory method to {{IAuthenticator}}, wouldn't it be
cleaner to add a {{withCertificates(Certificate[])}} method with a default
no-op implementation to {{SaslNegotiator}}? That way, the branching in
{{ServerConnection}} is simplified, the need for the {{Optional}} is removed
(because we just don't call it if the certs are null) and {{IAuthenticator}}
impls which don't care about certs don't have to change at all.
> 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)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
