[jira] [Assigned] (CASSANDRA-5112) Setting up authentication tables with custom authentication plugin

["Aleksey Yeschenko (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CASSANDRA-5112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Aleksey Yeschenko reassigned CASSANDRA-5112:
--------------------------------------------

    Assignee: Aleksey Yeschenko
    
> 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
>            Assignee: Aleksey Yeschenko
>            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