[
https://issues.apache.org/jira/browse/CASSANDRA-4898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13489603#comment-13489603
]
Dirkjan Bussink commented on CASSANDRA-4898:
--------------------------------------------
Well, on the validateConfiguration() issue, the thing here is more that it
might be useful to check whether the KS and CF's for authentication exist.
On the other hand, if an implementation like this would be provided as
standard, there could always be a setup of default authentication credentials.
Regarding the all node strategy, how exactly does this work? Are permissions
cached for a certain client? I could imagine it being a relatively big overhead
if the permission check needs to be made for example for each single write over
the same connection with the same credentials.
Currently I'm using StorageProxy.read (reading password and permissions) and
StorageProxy.mutate (handling grants) and I'm not going crazy because of that
:). These are btw the column families I'm using atm (using the custom strategy
but of course not necessary): https://gist.github.com/7231bc6d23331ecfb07b
The only thing that needs some explanation there is probably the serialization
format. The password is a combination of PBKDF2 iterations, key length, salt
and hash. The permissions is a long which is composed of two 32 bit masks, one
for the grant rights and one for the access rights. Since Permission explicitly
states the ordinal values can be used, I chose to do that.
> 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
