Dirkjan Bussink created CASSANDRA-5112:
------------------------------------------
Summary: Setting up authentication tables with custom
authentication plugin
Key: CASSANDRA-5112
URL: https://issues.apache.org/jira/browse/CASSANDRA-5112
Project: Cassandra
Issue Type: Improvement
Components: API
Affects Versions: 1.2.0
Reporter: Dirkjan Bussink
Priority: Minor
I'm working on updating https://github.com/nedap/cassandra-auth with the new
authentication API's in Cassandra 1.2.0. I have stumbled on an issue and I'm
not really sure how to handle it.
For the authentication I want to setup additional column families for the
passwords and permissions. As recommended in the documentation of IAuthorizer,
I'm trying to create these tables during setup(): "Setup is called once upon
system startup to initialize the IAuthorizer. For example, use this method to
create any required keyspaces/column families.".
The problem is that doing this seems to be a lot harder than I would think, or
I'm perhaps missing something obvious. I've tried various attempts, but all
have failed:
- CQL and QueryProcessor.processInternal to setup additional column families.
This fails, since processInternal will throw a UnsupportedOperationException
due to it being a SchemaAlteringStatement.
- CQL and QueryProcessor.process. This works after the system has successfully
started, but due to the moment setup() is called in the Cassandra boot process,
it will fail. It will throw an AssertionError in MigrationManager.java:320,
because the gossiper hasn't been started yet.
- Internal API's. Mimicking how other column families are set up, using
CFMetadata and Schema.load. This seems to get the system in some inconsistent
state where some parts do see the additional column family, but others don't.
Does anyone have a recommendation for the path to follow here? What would be
the recommended approach for actually setting up those column families during
starting for authentication?
>From working on this, I also have another question. I see the default
>system_auth keyspace is created with a SimpleStrategy and a replication factor
>of 1. Is this a deliberate choice? I can imagine that if a node in a cluster
>dies, losing the authentication information that happens to be available on
>that code could be very problematic. If I'm missing any reasoning here, please
>let me know, but it struck me as something that could cause potential
>problems. I also don't see a way I could reconfigure this at the moment, and
>API's such as CREATE USER do seem to depend on this keyspace.
--
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
