Authentication in DataStax drivers
The DataStax drivers support Apache Cassandra™ authentication and DSE Unified Authentication.
The DataStax drivers support Apache Cassandra™ authentication and DSE Unified Authentication.
- internal username and password authentication
- LDAP or Active Directory authentication
- Kerberos authentication
DSE's Unified Authentication provides the ability to assign users to roles and to tie access to database resources based on that role. DSE also allows users to login and execute using proxy roles. All of these features are enabled directly in the DataStax drivers, with built-in classes to enable the desired security configuration.
The DataStax drivers ship with built-in authentication providers that provide the necessary utilities to connect to a secured DSE cluster.
By default, DSE has no authentication service enabled. This makes it easy to get started but is not intended for production deployments. Before configuring the driver to use authentication, enable the desired security schemes within DSE and create users and roles in the database.
Authenticating with internal or LDAP usernames and passwords
The drivers use a plain text authentication provider to perform both DSE’s internal and LDAP or Active Directory authentication. The driver will send 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.
C/C++ | C# | Java | Node.js | PHP | Python | Ruby |
Authenticating with Kerberos
Each driver extends authentication providers to perform DSE’s Kerberos authentication.
Kerberos uses a krb5.conf file for configuration. Credentials can reside in a ticket cache or a keytab.
The krb5.conf configuration file
DSE driver authentication against a Kerberos-enabled DSE cluster requires a krb5.conf file containing the Kerberos configuration settings. This file may be in the node's /etc directory. If it is not, 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
krb5.conf. Kerberos command line tools such as kinit
,
klist
, and kdestroy
respect this variable.
All drivers except Java and C# 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.
The Kerberos ticket cache
To use the Kerberos
ticket cache, use the kinit
command
to authenticate with the Kerberos server and obtain a ticket. 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, the driver will arbitrarily choose one and use 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 should be set to allow the application user to access the keytab.
Proxy login and execution
Proxy login allows users to authenticate using a fixed set of authentication credentials but allow authorization of resources based on another user role. To use proxy login, see the documentation for the individual drivers.
C/C++ | C# | Java | Node.js | PHP | Python |
Like proxy login, proxy execute allows users to authenticate using a fixed set of authentication credentials but execute requests based on another user role. To use proxy execute, see the documentation for the individual drivers.
C/C++ | C# | Java | Node.js | PHP | Python |