Dirkjan Bussink created CASSANDRA-4898:
------------------------------------------
Summary: Authentication provider in Cassandra itself
Key: CASSANDRA-4898
URL: https://issues.apache.org/jira/browse/CASSANDRA-4898
Project: Cassandra
Issue Type: Improvement
Affects Versions: 1.1.6
Reporter: Dirkjan Bussink
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 yet.
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: http://www.atlassian.com/software/jira
