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
-
Kerberos 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.
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.
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 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. |
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.
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.
