[jira] [Commented] (CASSANDRA-10956) Enable authentication of native protocol users via client certificates

["Sam Tunnicliffe (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CASSANDRA-10956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15193168#comment-15193168 ] 

Sam Tunnicliffe commented on CASSANDRA-10956:
---------------------------------------------

Thanks for the patch, I second [~spodxx@gmail.com]'s comment that this looks a really useful addition. 

I don't think that extending {{IAuthenticator}} is necessarily the right way to go though. Making {{ICertificateAuthenticator}} a standalone top level interface makes the options around failure handling cleaner, because then it's pretty straightforward to first attempt cert based auth, but optionally on to fall back to SASL if necessary. To illustrate, I've pushed a branch [here|https://github.com/beobal/cassandra/tree/10956-trunk-v2] with an additional commit on top of the patch. As well as being able to specify a cert-based authenticator in cassandra.yaml, admins can also set the requirement level of that authentication, from a choice of 3 options: {{REQUIRED}}, {{NOT_REQUIRED}}, {{OPTIONAL}}. These new settings are in the {{client_encryption_options}} section of cassandra.yaml.

* Choosing {{REQUIRED}} means that clients *must* provide credentials via the certificate (and hence the server should only accept encrypted connections). Futhermore, those credentials *must* be valid & the associated role *must* have {{LOGIN}} privilege. 
* {{OPTIONAL}} also prioritizes cert based auth, but should it fail for any reason, the server falls back to the existing auth mechanism however that is configured in cassandra.yaml.
* {{NOT_REQUIRED}} is the default if no other option is set in the yaml, meaning cert based auth is disabled and the connection is established as it is currently. There's probably no reason for an admin to actually configure in this way, so it could be rejected (with an appropriate warning) if explicitly set.

[~sklock], [~spodxx@gmail.com] what are your thoughts on this approach?


> 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)