Configure Single Sign-On

Learn how to enable OpenID Connect SSO providers.

In TileDB Cloud Self-Hosted, it is possible to use configuration values to enable OpenID Connect (OIDC) single sign-on (SSO). Enabling one or more SSO providers allows TileDB Cloud Self-Hosted to use an existing identity management provider.

To configure SSO for your TileDB Cloud Self-Hosted installation, add the following to your values.yaml file, filling in your specific SSO details in the OIDC key:

# This configuration contains the necessary values to enable Single Sign-On (SSO) for
# Company integration with TileDB Cloud. By configuring these settings, the OpenID
# Connect (OIDC) component of the TileDB Cloud Rest Server is activated, thereby
# facilitating SSO both in the TileDB Cloud UI and the backend services. Customize
# the SSO parameters by replacing the placeholder values listed below with your
# specific SSO details. Pass these values alongside `values.yaml` to enable SSO
tiledb-cloud-rest:
  restConfig:
    SSO:
      OIDC: [] # List of SSO OIDC configurations. Replace placeholders with SSO details.
      # Example configuration:
      # - Domain: <SSO_Domain>
      #   OIDCIssuer: <SSO_OIDC_Issuer_URL>
      #   OIDCClientID: <SSO_Client_ID>
      #   OIDCClientSecret: <SSO_Client_Secret>

tiledb-cloud-ui:
  config:
    # This enables the toggle
    EnableCompanySSO: true # Enable SSO for the TileDB Cloud UI.

Claim rewriting

If your OpenID Connect implementation doesn’t provide data in the necessary format, you can configure TileDB Cloud to rewrite the claims to get what it needs. This is configured by setting the ClaimMapping key for the specific OIDC entry to {"target": "template string with {other}"}, where target is the claim to which TileDB will write the data, and template string with {other} is a string where the text {other} will be replaced by the other claim in the source claims.

In this case, performing the above substitution on an OpenID Connect token with the following claims:

{ "claim1": "example", "other": "data" }

will result in the addition of a target claim:

{ "claim1": "example", "other": "data", "target": "template string with data" }

For instance, if the OIDC claim doesn’t include an email, but it does include a preferred_username claim with a bare username, you can configure the substitution:

{ "email": "{preferred_username}@mycompany.example" }

This will transform a token like:

{ "iss": "some_issuer", "sub": "some_sub", "preferred_username": "the-user" }

into

{
  "iss": "some_issuer",
  "sub": "some_sub",
  "preferred_username": "the-user",
  "email": "the-user@mycompany.example"
}

Alternately, if your preferred_username field is already a full email address, you can omit the suffix:

{ "email": "{preferred_username}" }

Configuration file

You can customize these parameters by replacing the example values listed below with details for your specific SSO service’s OpenID Connect configuration.

# The tiledb-cloud-rest.restConfig.SSO.OIDC field contains server-side configuration
# to allow users to log in with SSO.
tiledb-cloud-rest:
  restConfig:
    SSO:
      # The "OIDC" key is a list of OpenID Connect configurations,
      # one for each email domain.
      OIDC:
        - Domain: mycompany.example
          OIDCIssuer: https://sso.mycompany.example/oidc-issuer
          OIDCClientID: tiledb-client-id
          OIDCClientSecret: tiledb-client-secret
          ClaimMapping: { "email": "{preferred_username}@mycompany.example" }
          # If you have users logging in with more than one email domain,
          # you can use multiple OpenID Connect configurations.
          # They may use the same issuer or a different one, as needed.
        - Domain: subsidiary.example
          OIDCIssuer: https://sso.mycompany.example/subsidiary-login
          OIDCClientID: other-client-id
          OIDCClientSecret: other-client-secret
          # If the ClaimMapping entry is missing, the claims are not modified.
# Setting tiledb-cloud-ui.config.EnableCompanySSO shows the "Corporate SSO" button
# in the TileDB Cloud web login screen.
tiledb-cloud-ui:
  config:
    EnableCompanySSO: true

On-Behalf-Of Flow

The On-Behalf-Of (OBO) Flow is a scenario in OAuth 2.0 where a client application (middle-tier service) uses an access token obtained through another OAuth flow (e.g., Authorization Code Flow or Client Credentials Flow) to call another web API (downstream service) on behalf of the original user.

TileDB Cloud supports using Microsoft identity platform and OAuth 2.0 On-Behalf-Of flow to provide tokens that can be used from TileDB Cloud API clients to access REST server with a scope of *.

Configuration file

Customize these parameters by replacing the example values listed below with details for your specific OBO configuration.

tiledb-cloud-rest:
  restConfig:
    SSO:
      OnBehalfOfToken:
        Audience: <aud JWT field>
        Issuer: https://login.microsoftonline.com/<TenantID>/v2.0
        TenantID: <TenantID>
        IntegrationType: Microsoft