[
https://issues.apache.org/jira/browse/CASSANDRA-10956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15210484#comment-15210484
]
Sam Tunnicliffe commented on CASSANDRA-10956:
---------------------------------------------
bq. The main risk is that it can make authentication somewhat more complex.
For the record, this is my concern too. I'm certainly uncomfortable with
anything which adds complexity to the security setup or makes it harder to
reason about paths through it.
Ideally, I'd like to revisit the way that SASL is implemented in the CQL native
protocol, to support things like multiple authentication schemes and mechanism
negotiation. I don't believe that would be difficult to implement and would
give us everything we need to satisfy the requirements of this ticket. The
downside is that it requires a protocol change which of course entails changes
to driver, which needs to be coordinated via a protocol version bump. The good
news is that the next bump will probably happen in 4.0, which isn't that far
away.
I'll open a ticket shortly to capture this and link it to CASSANDRA-9362, but
on balance then, I'm leaning towards wont-fixing this ticket rather than adding
new stuff here only to obsolete it relatively soon after. Sorry that that
somewhat negates the effort put in already, but that's preferable to adding
debt and complexity, especially in this area.
> Enable authentication of native protocol users via client certificates
> ----------------------------------------------------------------------
>
> Key: CASSANDRA-10956
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10956
> Project: Cassandra
> Issue Type: New Feature
> Reporter: Samuel Klock
> Assignee: Samuel Klock
> Attachments: 10956.patch
>
>
> Currently, the native protocol only supports user authentication via SASL.
> While this is adequate for many use cases, it may be superfluous in scenarios
> where clients are required to present an SSL certificate to connect to the
> server. If the certificate presented by a client is sufficient by itself to
> specify a user, then an additional (series of) authentication step(s) via
> SASL merely add overhead. Worse, for uses wherein it's desirable to obtain
> the identity from the client's certificate, it's necessary to implement a
> custom SASL mechanism to do so, which increases the effort required to
> maintain both client and server and which also duplicates functionality
> already provided via SSL/TLS.
> Cassandra should provide a means of using certificates for user
> authentication in the native protocol without any effort above configuring
> SSL on the client and server. Here's a possible strategy:
> * Add a new authenticator interface that returns {{AuthenticatedUser}}
> objects based on the certificate chain presented by the client.
> * If this interface is in use, the user is authenticated immediately after
> the server receives the {{STARTUP}} message. It then responds with a
> {{READY}} message.
> * Otherwise, the existing flow of control is used (i.e., if the authenticator
> requires authentication, then an {{AUTHENTICATE}} message is sent to the
> client).
> One advantage of this strategy is that it is backwards-compatible with
> existing schemes; current users of SASL/{{IAuthenticator}} are not impacted.
> Moreover, it can function as a drop-in replacement for SASL schemes without
> requiring code changes (or even config changes) on the client side.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
