Configuring internal authentication and authorization

Set internal authentication and authorization at the same time, then set object permissions.

You must set internal authentication and authorization at the same time. After setting the Authorizer and the Authenticator in the cassandra.yaml file, you can set object permissions, as described in Managing object permissions using internal authorization.

The location of the cassandra.yaml file depends on the type of installation:

Package installations	/etc/cassandra/cassandra.yaml
Tarball installations	`install_location`/resources/cassandra/conf/cassandra.yaml

Procedure

Perform the first three steps on every node.

Change the authenticator option in the cassandra.yaml to the native Cassandra PasswordAuthenticator by uncommenting only the PasswordAuthenticator:
```
authenticator: org.apache.cassandra.auth.PasswordAuthenticator
```
You can use any authenticator except AllowAll.

Change the authorizer option by commenting the AllowAllAuthorizer and adding the CassandraAuthorizer:

#authorizer: org.apache.cassandra.auth.AllowAllAuthorizer
authorizer: org.apache.cassandra.auth.CassandraAuthorizer

Restart the node.

Note: You can enable internal authorization on existing clusters with no downtime.
On one node, configure the system_auth keyspace replication factor.

Fetching permissions can be an expensive operation. If necessary, adjust the validity period for permissions caching by setting the permissions_validity_in_ms option in the cassandra.yaml. You can also disable permission caching by setting this option to 0.
Run a full repair of the system_auth keyspace.
Start cqlsh using the same superuser name and password (cassandra) that you use to start the supported client. For example, to start cqlsh on Linux:
```
./cqlsh -u cassandra -p cassandra
```
Note: Use the default cassandra user only to assist with initial setup of new users and superusers, and then delete it.
- Logins for the cassandra user are performed with QUORUM consistency.
  Do not use the cassandra user in production, because QUORUM consistency has significant performance degradation for multiple data centers.
- Logins for all other users are performed with LOCAL_ONE consistency.
Change the superuser's user name and password.