[
https://issues.apache.org/jira/browse/CASSANDRA-11471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15941051#comment-15941051
]
Ben Bromhead edited comment on CASSANDRA-11471 at 3/24/17 8:06 PM:
-------------------------------------------------------------------
Sorry for the delay, the joy of a new baby :)
Addressed all the comments except one.
bq. Only if encryption is optional? Basically because the authenticator can
only work if the certificates are there? It seems like this can NPE?
Currently getSaslNegotiator will try to get the certificate chain from the
channel if client encryption is enabled and connecting on an encrypted session
is not optional.
This means null instead of a certificate chain will be passed in when getting
the new SASL authenticator. I couldn't think of a nice way to pass the
certificate chain to the authenticator but still respect the fact there are
authenticators that just don't care about them.
Originally my thinking was that Optional does not appear to be used in the
project and I didn't want to add even more more methods to IAuthenticator.
Thinking about it again, it probably just makes sense to overload
newV5SaslNegotiator and not have to pass in certificates, which would reduce
the chance of someone implementing a new Authenticator getting an NPE.
||4.0||
|[Branch|https://github.com/apache/cassandra/compare/trunk...benbromhead:11471]|
was (Author: benbromhead):
Sorry for the delay, the joy of a new baby :)
Addressed all the comments except one.
bq. Only if encryption is optional? Basically because the authenticator can
only work if the certificates are there? It seems like this can NPE?
Currently getSaslNegotiator will try to get the certificate chain from the
channel if client encryption is enabled and connecting on an encrypted session
is not optional.
This means null instead of a certificate chain will be passed in when getting
the new SASL authenticator. I couldn't think of a nice way to pass the
certificate chain to the authenticator but still respect the fact there are
authenticators that just don't care about them.
Given that Optional does not appear to be used in the project and I didn't want
to add even more more methods to IAuthenticator. Thinking about it again, it
probably just makes sense to overload newV5SaslNegotiator and not have to pass
in certificates, which would reduce the chance of someone implementing a new
Authenticator getting an NPE.
||4.0||
|[Branch|https://github.com/apache/cassandra/compare/trunk...benbromhead:11471]|
> 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
> 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)
