cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-4898) Authentication provider in Cassandra itself
Date Thu, 14 Feb 2013 21:27:13 GMT


Jonathan Ellis commented on CASSANDRA-4898:

LGTM.  Okay with the class names.
> Authentication provider in Cassandra itself
> -------------------------------------------
>                 Key: CASSANDRA-4898
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>    Affects Versions: 1.1.6
>            Reporter: Dirkjan Bussink
>            Assignee: Aleksey Yeschenko
>              Labels: authentication, authorization
>             Fix For: 1.2.2
> I've been working on an implementation for both IAuthority2 and IAuthenticator that uses
Cassandra itself to store the necessary credentials. I'm planning on open sourcing this shortly.
> Is there any interest in this? It tries to provide reasonable security, for example using
PBKDF2 to store passwords with a configurable configuration cycle and managing all the rights
available in IAuthority2. 
> My main use goal isn't security / confidentiality of the data, but more that I don't
want multiple consumers of the cluster to accidentally screw stuff up. Only certain users
can write data, others can read it out again and further process it.
> I'm planning on releasing this soon under an open source license (probably the same as
Cassandra itself). Would there be interest in incorporating it as a new reference implementation
instead of the properties file implementation perhaps? Or can I better maintain it separately?
I would love if people from the community would want to review it, since I have been dabbling
in the Cassandra source code only for a short while now.
> During the development of this I've encountered a few bumps and I wonder whether they
could be addressed or not.
> = Moment when validateConfiguration() runs =
> Is there a deliberate reason that validateConfiguration() is executed before all information
about keyspaces, column families etc. is available? In the current form I therefore can't
validate whether column families etc. are available for authentication since they aren't loaded
> I've wanted to use this to make relatively easy bootstrapping possible. My approach here
would be to only enable authentication if the needed keyspace is available. This allows for
configuring the cluster, then import the necessary authentication data for an admin user to
bootstrap further and then restart every node in the cluster.
> Basically the questions here are, can the moment when validateConfiguration() runs for
an authentication provider be changed? Is this approach to bootstrapping reasonable or do
people have better ideas?
> = AbstractReplicationStrategy has package visible constructor =
> I've added a strategy that basically says that data should be available on all nodes.
The amount of data use for authentication is very limited. Replicating it to every node is
there for not very problematic and allows for every node to have all data locally available
for verifying requests.
> I wanted to put this strategy into it's own package inside the authentication module,
but since the constructor of AbstractReplicationStrategy has no visibility explicitly marked,
it's only available inside the same package.
> I'm not sure whether implementing a strategy to replicate data to all nodes is a sane
idea and whether my implementation of this strategy is correct. What do you people think of
this? Would people want to review the implementation?

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message