Skip to content

Configure Single Sign-On Enterprise

TestGen supports Single Sign-On (SSO) through any authentication provider that implements the OpenID Connect (OIDC) protocol, such as Okta, Microsoft Entra ID, or Auth0, or Ping Identity.

When SSO is enabled, users authenticate through your identity provider instead of using TestGen's built-in login. System administrators can still assign roles to users and manage project membership from the Administration console.

Prerequisites

  • TestGen instance installed as outlined in Install Enterprise or Install on Kubernetes.
  • An OIDC-compatible identity provider with a registered application. You will need: client ID, client secret, and the provider's server metadata URL.

Configure your identity provider

  1. Create a new application registration in your identity provider for TestGen.
  2. Set the redirect URI to the TestGen UI URL (for example, https://testgen.example.com).
  3. Grant the application the openid, profile, and email scopes.
  4. Note the client ID, client secret, and server metadata URL for use in the next step.

  5. Create an admin role in your identity provider and assign it to at least one user. Configure the provider to include assigned roles in the roles claim of the ID token.

    Warning

    At least one user must hold the admin role. Once single sign-on is enabled, the login page offers only the single sign-on option, and the role is the only way to reach the Administration console.

Create the sso_auth.toml file

Create a file named sso_auth.toml with the following content. Replace the placeholders with values from your identity provider, and set redirect_uri to the TestGen UI URL.

[auth]
redirect_uri = "<testgen-ui-url>"
cookie_secret = "<random-string>"
client_id = "<oidc-client-id>"
client_secret = "<oidc-client-secret>"
server_metadata_url = "https://<oidc-domain>/.well-known/openid-configuration"

Enable single sign-on

  1. Place sso_auth.toml in the directory that contains the docker-compose.yml file for TestGen.

  2. Set the following variables under the x-common-variables section.

    x-common-variables: &common-variables
 TG_USE_SSO_AUTH: yes
 TG_SSO_ROLES_CLAIM: roles

  3. Add the file as a bind mount on the engine service.

    services:
  engine:
    volumes:
      - type: bind
        source: ./sso_auth.toml
        target: /dk/.streamlit/secrets.toml

  4. Restart the application.

    docker compose up -d --wait

  1. Store sso_auth.toml in a secret.

    kubectl create secret generic testgen-sso -n datakitchen \
    --from-file=sso_auth.toml=./sso_auth.toml

  2. Add the following to the values-tg-app.yaml file used for the installation.

    extraEnv:
  - name: TG_USE_SSO_AUTH
    value: "yes"
  - name: TG_SSO_ROLES_CLAIM
    value: roles

extraVolumes:
  - name: sso
    secret:
      secretName: testgen-sso
      items:
        - key: sso_auth.toml
          path: secrets.toml

extraVolumeMounts:
  - name: sso
    mountPath: /dk/.streamlit
    readOnly: true

  3. Apply the change.

    helm upgrade -n datakitchen dk-tg-app datakitchen-testgen/testgen \
    --values values-tg-app.yaml --wait

To turn single sign-on off, remove TG_USE_SSO_AUTH and restart the application. The login page then offers local sign-in again.

How roles work with SSO

Each time a user signs in through SSO, TestGen checks the roles claim in the ID token for the value admin (case-insensitive). Users with the role get system administrator access, and users without it lose that access. A change to the role in your identity provider takes effect at the user's next sign-in.

To use a claim name other than roles, set the TG_SSO_ROLES_CLAIM environment variable. See Set Environment Variables.

Project roles (such as Data Quality or Analyst) do not come from the identity provider. System administrators assign them through project membership in the Administration console after the user's first sign-in.

User Access

Install Enterprise