[
https://issues.apache.org/jira/browse/CASSANDRA-10956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15154488#comment-15154488
]
Samuel Klock commented on CASSANDRA-10956:
------------------------------------------
Thank you for the feedback. I've left some replies to your comments on GitHub,
and we'll plan to incorporate your feedback in a new version of the patch in
the next few days.
Regarding anonymous authentication: would it be reasonable to make this
behavior configurable? The intent is to enable operators to provide some level
of access (perhaps read-only) to users who are not capable of authenticating. I
do agree that it hardcoding this behavior in
{{CommonNameCertificateAuthenticator}} probably isn't correct.
(It's also worth noting that the native protocol doesn't appear to support
authentication at all for existing {{IAuthenticators}} that don't require
authentication, so maybe {{ICertificateAuthenticator}} shouldn't support it
either.)
> 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)
