[
https://issues.apache.org/jira/browse/CASSANDRA-4898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13489470#comment-13489470
]
Jonathan Ellis commented on CASSANDRA-4898:
-------------------------------------------
IMO this would be a good candidate for a new reference implementation.
Note that IAuth2 is kind of broken (oops) and we'll be redoing that in
CASSANDRA-4874 and CASSANDRA-4875. I imagine most of your work though will be
around internals. (I would suggest using QueryProcessor.processInternal to
keep the pain level down -- see examples in SystemTable.)
bq. I'm not sure whether implementing a strategy to replicate data to all nodes
is a sane idea
This is overkill.
Suggest instead creating a system_auth keyspace, default to
SimpleStrategy/RF=1. Users can then change this using normal tools.
> 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
> Labels: authentication, authorization
>
> 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
