Skip to main content
This is a TrueFoundry High-tier Enterprise plan feature.
By default, the control plane uses the TrueFoundry Auth Server to authenticate users. However, you can deploy the control plane using your own external OIDC or SAML compliant identity provider instead.

Prerequisites

Before deploying the control plane with external OAuth/SAML:
  • Ensure you have an OIDC or SAML-compliant identity provider configured
  • Obtain the necessary credentials (Client ID, Client Secret, Issuer URL, etc.)
  • Contact TrueFoundry team to obtain the INTERNAL_JWT_JWKS value required for secure token signing
  • Verify network connectivity between your identity provider, user browsers, control plane, and AI Gateway servers
You need to add your OIDC application details under servicefoundryServer.env in the values.yaml file of truefoundry helm installation.
servicefoundryServer:
  env:
    OAUTH_PROVIDER_TYPE: "EXTERNAL"
    EXTERNAL_OAUTH_ISSUER: "<OIDC_ISSUER_URL>"
    EXTERNAL_OAUTH_CLIENT_ID: "<OIDC_CLIENT_ID>"
    EXTERNAL_OAUTH_CLIENT_SECRET: "<OIDC_CLIENT_SECRET>"

    INCLUDE_TRUEFOUNDRY_MANAGED_JWKS: "false"
    INTERNAL_JWT_SERVICE_ENABLED: "true"
    INTERNAL_JWT_JWKS: "<INTERNAL_JWT_JWKS>" # Contact TrueFoundry support to obtain this value - required for secure token signing
tfy-llm-gateway:
  env:
    ENABLE_EXTERNAL_OAUTH: "true"
Store sensitive values like EXTERNAL_OAUTH_CLIENT_SECRET and INTERNAL_JWT_JWKS securely using Kubernetes secrets rather than plain text in values.yaml. Consider using a secrets management solution like HashiCorp Vault or sealed-secrets.

Optional Configuration Fields

Use these fields only if your identity provider returns user information with non-standard claim names:
servicefoundryServer:
  env:
    ## Optional: Customize if your IdP uses non-standard claim names
    # USE_ID_TOKEN_AS_ACCESS_TOKEN: boolean (default: false) - Set to true if your IdP doesn't provide separate access tokens
    # EXTERNAL_OAUTH_USER_INFO_EMAIL_KEY_NAME: string (default: "email") - Customize if email is not in the "email" field
    # EXTERNAL_OAUTH_USER_INFO_ID_KEY_NAME: string (default: "id")
    # EXTERNAL_OAUTH_USER_INFO_NAME_KEY_NAME: string (default: "name")
    # EXTERNAL_OAUTH_USER_INFO_FIRST_NAME_KEY_NAME: string (default: "firstName")
    # EXTERNAL_OAUTH_USER_INFO_LAST_NAME_KEY_NAME: string (default: "lastName")
    # EXTERNAL_OAUTH_USER_INFO_IMAGE_URI_KEY_NAME: string (default: "picture")
    # EXTERNAL_OAUTH_TOKEN_EMAIL_CLAIM_KEY_NAME: string (default: "email")
    # EXTERNAL_OAUTH_TOKEN_USERNAME_CLAIM_KEY_NAME: string (default: "username")
    # EXTERNAL_OAUTH_TOKEN_ID_CLAIM_KEY_NAME: string (default: "sub") - Customize if user ID is not in the "sub" claim
    # EXTERNAL_OAUTH_USER_INFO_USERNAME_KEY_NAME: string (default: "username")
Example: If your Okta setup returns user ID in a field called userId instead of sub, set:
EXTERNAL_OAUTH_TOKEN_ID_CLAIM_KEY_NAME: "userId"
Here we are assuming the identity provider is OIDC compliant and satisfies the following:
  1. OpenID configuration is available at <ISSUER_URL>/.well-known/openid-configuration.
  2. Scopes configured should include openid, email, profile and offline_access.
  3. Allowed Redirect URI should be set to <CONTROL_PLANE_URL>/auth/callback.
  4. OIDC issuer servers must be accessible (network connectivity with no firewall blocks) from user’s browser, TrueFoundry control plane servers, and all multi-zone AI Gateway servers.