Authentication in DataStax drivers
The DataStax drivers support Apache Cassandra™ authentication and DSE Unified Authentication.
To simplify and standardize DataStax Enterprise security features, Unified Authentication was introduced in DSE 5.0 to give operators and developers a single, flexible security model. A single DSE server can accept multiple forms of authentication:
internal username and password authentication
LDAP or Active Directory authentication
Clients with different levels of access can use varying authentication schemes to connect to the same DSE server.
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.
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.
Each driver extends authentication providers to perform DSE’s Kerberos authentication.
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 C# driver.
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
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
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.
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
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.
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.
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.