||
Skip to end of metadata
Go to start of metadata

With the User Management functionality that is built into WSO2 products, system administrators can define role-based permissions for tenant users. In WSO2 Storage Server, you can define role-based permissions for each of the Cassandra environments in your system. That is, as a tenant user, you will be allowed to add or edit the information in your Cassandra environment, only if the relevant permissions are granted. Therefore, this permission model provides the flexibility to maintain tenant-isolated Cassandra environments in your enterprise system. 

When you use the embedded Cassandra instance in Storage Server, you must configure the native Cassandra permissions, in addition to the permissions that are configured through user management. You can also disable the native Cassandra permissions for your server if required.

Therefore, note that when you configure embedded Cassandra, the native Cassandra permissions should not conflict with the permissions enabled in user management. For example, if a role should be allowed to create new keyspaces, this permission should be enabled for the role at user management level as well as through native Cassandra permissions.

The following topics explain role-based permissions and native Cassandra permissions in detail:

Enabling role-based Cassandra permissions

Role-based permissions are the general permissions that are granted to a role when the role is defined. When the Cassandra feature is installed in a product (as in WSO2 Storage Server), you can configure the permissions to manipulate the information in Cassandra environments. Note that, for SS embedded Cassandra, you need to configure the native Cassandra permissions, in addition to the role-based permissions described here.

Before you begin, all the Cassandra environments in your system should already be configured in the cassandra-environments.xml file (stored in the <SS_HOME>/repository/conf/etc/ directory), to be able to grant permissions for a role.

Shown below is how you can enable Cassandra permission for the default Cassandra environment:
 

Enabling native Cassandra permissions

This feature is only applicable for environments with embedded Cassandra clusters. That is, when you use the embedded Cassandra instance of a WSO2 Storage Server, you have the in-built Cassandra authentication and authorization functionality, which can enable a separate set of permissions for Cassandra. You have the option of disabling this function in your server if required. However, if the feature is enabled, note that the in-built Cassandra permissions as well as the role-based Cassandra permissions should not conflict with one another.

Configuring Cassandra authentication and authorization
  • In WSO2 Storage Server, to log in to embedded Cassandra, you need to be an authenticated Carbon user. The authentication class is configured in <SS_HOME>/repository/conf/etc/cassandra.yaml using the following authenticator: org.wso2.carbon.cassandra.server.CarbonCassandraAuthenticatorBy default, Cassandra authentication is enabled for all users in WSO2 Storage Server. If required, you can set this configuration to 'disable authentication' as explained below.

    # - AllowAllAuthenticator performs no checks - set it to disable authentication.
  • In WSO2 Storage Server, Cassandra authorization can be managed in a fine-grained manner. The authorizer class is configured in <SS_HOME>/repository/conf/etc/cassandra.yaml using the following authorizer: org.wso2.carbon.cassandra.server.CarbonCassandraAuthorizerBy default, Cassandra authorization is enabled for all users in WSO2 Storage Server. If required, you can set this configuration to 'disable authorization' as shown below.

    # - AllowAllAuthorizer allows any action to any user - set it to disable authorization
Enabling native Cassandra permissions

If the Cassandra authenticator and authorizer is enabled for the SS embedded Cassandra as explained in the previous step, you can enable or disable the native Cassandra permissions for a user role as explained below. Native Cassandra permissions can be enabled at three levels: all keyspacesindividual keyspace and column family. The permissions that can be enabled are CreateAlterDropSelectModify and Authorize.

Before you begin, note the following:

  • You need to have authorization permissions to set permissions for other roles. See more information about roles and permissions.
  • 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. 

To enable keyspace level authorization: 

  • Go to Manage > Cassandra Keyspaces > List. You can see the following page which allows you to manage root level permissions for each role.

To enable keyspace/Column family level authorization:

  • Go to Manage > Cassandra Keyspaces > List. 
  • Click Set Permissions in the list of actions for the keyspace. You can then manage the native permissions applicable to the column families in the keyspace.
  • No labels