Authentication and authorization

Authentication and authorization are sequential security processes. Authentication verifies a user’s identity, such as through a password or authentication app. Authorization, also known as access control or client privilege, grants a user or entity permission to access specific resources or functions. Typically, an organization’s administrators control authorization by assigning roles to users.

Authentication architecture for Astra DB Classic databases

Astra DB uses an authentication and authorization method, JSON web token (JWT) using open policy agent (OPA). The workflow below shows how this method bypasses Stargate using the Astra Authenticator, Astra IAM. All queries are then sent to DataStax Enterprise (DSE) to handle the authentication and authorization.

authnz

For databases on the Advanced Workloads tier, search and graph queries can be sent directly to Astra DB Classic. The authentication and authorization is performed by the authenticator and authorizer module using OPA.

Single sign-on

In addition to username and password authentication, Astra DB Classic supports single sign-on with multiple identity providers.

Sign in with a SAML IdP

You can sign in to the Astra Portal through your SAML IdP if your Organization Administrator has enabled SSO. DataStax supports any SAML-compatible IdP, including Entra ID, Okta, OneLogin, Google Identity Platform, and Ping Identity. For more information, see Configure single sign-on.

Sign in with Google

You can use your Gmail or Google Workspace account to create an Astra DB account and sign in to the Astra Portal.

Sign in with GitHub

You can use your GitHub account to create an Astra DB account and sign in to the Astra Portal.

To use GitHub for Astra DB authentication, you must have a public email address in your GitHub profile. If you are a new user, make your email public before you create an Astra DB account. If you are an existing user and you selected keep my email address private in your GitHub profile, you must make your email address public, and then change your password to switch to Astra DB local authentication. Alternatively, you can use another SSO option with the same email address as your GitHub account. If you don’t want to make your email address public, you must use a different SSO option or username and password authentication.

Application tokens

You can use application tokens to authorize API calls or application connections to your Astra DB databases.

Table-based authentication and authorization (deprecated)

The legacy Stargate APIs are deprecated for Astra DB Classic as of September 2024, and end-of-life (EOL) is scheduled for the end of 2025. As EOL approaches, DataStax will provide migration information to support your transition to other options.

If you have questions or concerns, contact your account representative or DataStax Support.

Table-based authentication and authorization for legacy APIs

Table-based authentication and authorization uses the Stargate Auth API to generate an auth token based on a Apache Cassandra® username and password. The auth-table-based-service uses the generated auth token to allow Stargate API queries access to your database.

By default, the token persists for 30 minutes with a sliding window. Each use of the token to authenticate resets the 30 minute window. A token created and used after 29 minutes will authenticate a request, but if 31 minutes pass before use, the token will no longer exist.

The length of time to persist the token is configurable using the system property stargate.auth_tokenttl. For example, the following configuration sets the token lifetime to 100 seconds:

JAVA_OPTS='-Dstargate.auth_tokenttl=100' ./starctl \
--developer-mode --cluster-name test --cluster-version 3.11 --enable-auth

You can use the REST API to generate an auth token:

curl -L -X POST "https://ASTRA_DB_ID-ASTRA_DB_REGION.apps.astra.datastax.com/api/rest/v1/auth" \
-H "Content-Type: application/json" \
--data-raw '{
  "username": "CLIENT_ID",
  "password": "CLIENT_SECRET"
}'

A successful response includes the authentication token:

{ "authToken": "AUTH_TOKEN" }

You must provide this token in each subsequent request in the X-Cassandra-Token header. You can provide the token directly in the header or export it as an environment variable.

  • REST or Document API (v2)

  • GraphQL

Store the auth token in an environment variable to make it easy to use with HTTP:

export AUTH_TOKEN=AUTH_TOKEN

Add the auth token to the HTTP Headers box in the GraphQL playground:

{ "X-Cassandra-Token": "AUTH_TOKEN" }

Was this helpful?

Give Feedback

How can we improve the documentation?

© 2024 DataStax | Privacy policy | Terms of use

Apache, Apache Cassandra, Cassandra, Apache Tomcat, Tomcat, Apache Lucene, Apache Solr, Apache Hadoop, Hadoop, Apache Pulsar, Pulsar, Apache Spark, Spark, Apache TinkerPop, TinkerPop, Apache Kafka and Kafka are either registered trademarks or trademarks of the Apache Software Foundation or its subsidiaries in Canada, the United States and/or other countries. Kubernetes is the registered trademark of the Linux Foundation.

General Inquiries: +1 (650) 389-6000, info@datastax.com