Authentication in Cassandra drivers
The DataStax-compatible drivers ship with built-in authentication providers that provide the necessary utilities to connect to secure Apache Cassandra®-based clusters.
You must configure your preferred authentication method in your clusters before attempting to use that authentication method through a driver.
Cassandra authentication
For information about authentication in open-source Cassandra clusters, see the Apache Cassandra security documentation.
Astra DB authentication
Driver authentication to Astra DB is handled through application tokens and each database’s Secure Connect Bundle (SCB).
The application token determines the authorized actions that the driver can perform on the database, and the SCB contains the security credentials and certificates required to establish a secure mutual TLS (mTLS) connection to your database.
For more information, see Manage application tokens and Download and use a Secure Connect Bundle (SCB) with Astra DB Serverless.
DSE and HCD authentication
DSE and HCD have no authentication service enabled by default. This simplifies initial setup, but it isn’t intended for production deployments. Before configuring the driver to use authentication, enable the desired security schemes within your clusters and create users and roles in the database.
Unified authentication
Both DSE and HCD offer unified authentication to give operators and developers a single, flexible security model. A single DSE or HCD server can accept multiple forms of authentication:
-
Internal username and password authentication
-
LDAP or Active Directory authentication
-
Kerberos authentication
Clients with different levels of access can use varying authentication schemes to connect to the same server.
Unified authentication provides the ability to assign users to roles and to tie access to database resources based on that role. DSE and HCD also support proxy roles, such as HCD’s application roles.
All of these features are enabled directly in the DataStax-compatible drivers, with built-in classes to enable the desired security configuration.
For more information about configuring unified authentication, see Unified authentication in DSE and Unified Authentication in HCD.
Internal or LDAP usernames and passwords
The drivers use a plain text authentication provider to perform internal and LDAP/Active Directory authentication.
For DSE and HCD, the driver sends a plain text username and password to the server, which will authenticate to the underlying configured scheme.
Because these mechanisms transmit credentials in clear text in the native protocol, they should always be used in conjunction with client-server transport encryption.
Kerberos
Each driver extends authentication providers to support Kerberos authentication for DSE and HCD.
|
The C# driver uses the Microsoft security framework called SSPI, which supports Kerberos. When using the C# driver, a Kerberos ticket is obtained during system login and the driver uses that ticket to authenticate. The rest of this section does not apply to the DSE-only C# driver. |
Kerberos configuration file
Driver authentication against a Kerberos-enabled DSE cluster requires a krb5.conf file containing the Kerberos configuration settings.
This file can be in the node’s /etc directory.
If it isn’t, contact your Kerberos system administrator to locate the file.
To reference a krb5.conf file in a non-default location, set the KRB5_CONFIG environment variable to the location of your krb5.conf.
Kerberos command line tools such as kinit, klist, and kdestroy respect this variable.
All drivers except the Java and C# drivers respect this environment variable.
Java clients must set the java.security.krb5.conf system property to the path to the krb5.conf file at startup.
The C# driver uses SSPI, which doesn’t use krb5.conf.
Kerberos ticket cache
To use the Kerberos ticket cache, use the kinit command to authenticate with the Kerberos server and obtain a ticket.
Then, verify the ticket cache contains a ticket for the successful authentication with the klist command.
Once you verify there is a ticket in the ticket cache, an application that has been configured to use the Kerberos authentication provider is ready to run.
If multiple principals have valid tickets in the ticket cache, and no principal was specified in the application, then the driver arbitrarily chooses one and uses that ticket.
Kerberos keytabs
A keytab can be used to authenticate with Kerberos without requiring any additional credentials or a password. Keytab files must have their permissions set properly to restrict access. The permissions must be set to allow the application user to access the keytab.
Proxy login and execution
DSE and HCD support proxy login, which allows users and applications to authenticate using a fixed set of authentication credentials that allow authorization of resources based on another user role.
Similarly, proxy execute allows users to authenticate using a fixed set of authentication credentials but execute requests based on another user role.
To use proxy login and proxy execute, see your driver’s documentation:
