About Internal authentication

Internal authentication stores login roles and passwords in the database.

Internal authentication provides the following types of roles:
  • Login roles: Validate a user's identity (password) and control access to database resources
  • Permission set (non-login) roles: Allows assignment of the same privileges to one or more users (login roles). A role access permissions are inherited but the role options (superuser, login and password) are not. The database supports nesting roles to create a permission hierarchy.
The diagram below shows four login accounts with four group roles.
Figure 1. Roles assigned to individuals and functions

Setting up the administrator accounts

Use the following steps to set up user logins alice and fred and grant them administrator access to the cycling keyspace.

  1. Create login accounts for each user. For example, alice is created with the ability to login and given a password:
    CREATE ROLE alice WITH PASSWORD = 'enjoyLife' AND LOGIN = true;
          
          CREATE ROLE fred WITH PASSWORD = 'enjoyLife' AND LOGIN = true;
    The user enters the role name and password to log into the database. However at this point the role only has default access to some system tables.
    Tip: Roles options include superuser, login, and password options. A superuser can perform any database operations.
  2. Create a role with access to all the functionality for the cycling keyspace. The first command creates the role and the second assigns the privileges:
    CREATE ROLE cycling_admin 
          WITH PASSWORD = '1234abcd';
          
          GRANT ALL PERMISSIONS 
          ON KEYSPACE cycling 
          TO cycling_admin;

    When the cycling_admin role is assigned to a login role, all the permissions are inherited. This gives any user that is a member of the cycling_admin role full access to the cycling keyspace.

  3. Assign the cycling_admin role to alice and fred:
    GRANT cycling_admin TO alice;
          GRANT cycling_admin TO fred;

    When alice is granted the role cycling_admin, alice is now granted all permissions on the keyspace cycling. Individual user can be granted any number of roles, just as any functional role can be granted another role's permissions.

In this example, the role cycling_analyst has the ability to select data, and then gains the ability to select data in the another table hockey when the role hockey_analyst is granted.
CREATE ROLE cycling_analyst WITH PASSWORD = 'zyxw9876';
        GRANT SELECT ON TABLE cycling.analysis TO cycling_analyst;
        CREATE ROLE hockey_analyst WITH PASSWORD = 'Iget2seeAll';
        GRANT SELECT ON TABLE hockey.analysis TO hockey_analyst;
        GRANT hockey_analyst TO cycling_analyst;
        GRANT cyclist_analyst TO jane;
If a user then is granted the role of cycling_analyst role, that user is able to select data in the additional table hockey.
Note: Permissions and SUPERUSER status are inherited, but the LOGIN privilege is not.
An important change that roles-based access control also introduces is that the need for SUPERUSER privileges in order to perform user/role management operations is removed. A role can be authorized to create roles or be authorized to grant and revoke permissions:
// Give cycling_accounts the right to create roles
        GRANT CREATE ON ALL ROLES TO cycling_accounts;
        // Give cycling_accounts the right to grant or revoke permissions
        GRANT AUTHORIZE ON KEYSPACE cycling TO cycling_accounts;
        GRANT cyclist_accounts TO jane;
        GRANT cyclist_accounts TO john;
Internal authentication and authorization information is stored in the following tables:
system_auth.roles
Table that stores the role name, whether the role can be used for login, whether the role is a superuser, what other roles the role may be a member of, and a bcrypt salted hash password for the role.
system_auth.role_members
Table that stores the roles and role members.
system_auth.role_permissions
Table that stores the role, a resource (keyspace, table), and the permission that the role has to access the resource.
system_auth.role_permissons_index
Table that stores the role and a resource that the role has a set permission.
The database has a default superuser role and password pair of cassandra/cassandra by default. Only use this role to create your own superuser account because all request from the default account run with a consistency level of QUORUM. To secure the system, delete the default account after creating a superuser account.

Once roles and passwords have been set, the database can be configured to use authentication in the cassandra.yaml file.

After authentication is enabled, specify a username and password when using database tools and drivers. For details refer to the following sections: