[
https://issues.apache.org/jira/browse/CASSANDRA-10956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15163275#comment-15163275
]
Stefan Podkowinski commented on CASSANDRA-10956:
------------------------------------------------
bq. 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 have a similar use case where we like to use different authenticators for
application logins and employees. The idea would be to use
{{PasswordAuthenticator}} for applications and LDAP for human users. One way to
implement this would be to create a chain of individual authenticators that are
to be checked by order, maybe with a default action if all of them fail
(deny/anonymous). However, as you probably also want to use a different role
manager depending on used authenticator, you'd need some kind of mapping for
that as well and I don't like to end up creating iptables for the Cassandra
login process.
Maybe the better option would be to allow configuring multiple native transport
ports, each of them using a single authenticator and role manager. This should
be relatively easy to implement and would also allow to restrict access on
network level, e.g. setting up different firewall rules for the "applications"
or "developer" ports.
> 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)
