Cassandra Authentication and Authorization
- Former user (Deleted)
Authentication
In Storage Server, to login to Cassandra you need to be an authenticated Carbon user. The authentication class is configured in <SS_HOME>/repository/conf/etc/cassandra.yaml and the authenticator used is: org.wso2.carbon.cassandra.server.CarbonCassandraAuthenticator.
Authorization
Cassandra authorization can be managed in a fine-grained manner. The authorizer class is configured in <SS_HOME>/repository/conf/etc/cassandra.yaml and the authorizer used is: org.wso2.carbon.cassandra.server.CarbonCassandraAuthorizer.
Storage server supports Cassandra’s native permissions which are Create, Alter, Drop, Select, Modify and Authorize. Those can be granted to users in three resource levels namely: Root level, Keyspace level and Column Family level.
Root level authorization
When you go to Manage > Cassandra Keyspaces > List you can see the following page which allows you to manage root level permissions for each role.
Keyspace/Column family level authorization
Permissions can be set for each keyspace and column family using ‘Set Permission’ link in the Actions column of each Keyspace/Column Family.
- You need to have authorization permissions to set permissions for other roles.
- If a role has a particular permission for a resource in some level, that role implicitly gets the same permission for all lower levels of that resource.
- Cassandra caches its permissions. You can set cache expiry time in
<SS_HOME>/repository/conf/etc/cassandra.yaml(the default is 2000ms).permissions_validity_in_ms: 2000
Be careful when you increase this value because Cassandra does not invalidate the permission cache when permissions are updated. It only invalidates this cache after the expiry time.