[
https://issues.apache.org/jira/browse/CASSANDRA-10956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15195354#comment-15195354
]
Samuel Klock commented on CASSANDRA-10956:
------------------------------------------
Thanks Sam and Stefan.
bq. The reason for presenting this option in the yaml config is not really
clear to me. It’s contrary to the idea of using the certificate authenticator.
To obtain the same behavior as {{NOT_REQUIRED}}, would it make sense to allow
leaving {{authenticator}} unset? Then it could default to {{null}}. If we
don't want to special-case {{null}} in the code, then
{{NoOpCertificateAuthenticator}} could simply use {{OPTIONAL}} and always throw
an {{AuthenticationException}} from {{authenticate()}}.
bq. I’d assume that authentication should be handled by providing a
IAuthenticator implementation, but I can see how this is not a good fit here as
we can’t provide any SASL support.
I think we'd be comfortable with Sam's scheme. The main risk is that it can
make authentication somewhat more complex: now there could be more than one way
to authenticate to a role, and one way could take priority over other ways. On
the other hand, based on Stefan's comments, it sounds like there are use cases
for schemes like this.
It's also worth noting that RFC 4422 specifies a mechanism that could support
certificate authentication ([the EXTERNAL
mechanism|https://tools.ietf.org/html/rfc4422#appendix-A]). The obstacle to
using EXTERNAL is that AFAICT Cassandra doesn't expose an interface to SASL
authenticators for obtaining data about the context (e.g., whether TLS is in
use and, if so, what certificates the client presented). I think exposing such
an interface would be a more general solution, but (at least at first glance)
it could also be a significantly more complicated change.
> 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)
