Skip to main content
This page tells a BYOC operator what to configure before an administrator enables single sign-on.
This page applies to BYOC deployments only. On Lerian Cloud, Lerian operates this configuration for you.

​
Set one callback URL

Set PLUGIN_AUTH_SSO_CALLBACK_URL on both the Auth and Identity services. Use the exact public Console callback URL:
Auth sends this URL to the identity provider. Identity includes it in the allowed redirect configuration.
Use the same absolute URL in Auth, Identity, the Console, and the identity-provider application. A scheme, host, or path mismatch makes the authorization-code exchange fail.

​
Configure Console routes

The Console needs these routes: Set PLUGIN_AUTH_PUBLIC_BASE_PATH to an HTTPS address that the user’s browser can reach. The browser follows the redirect from the SSO start operation directly. With the Product Console Helm chart, set the server-to-server routes in configmap and the browser-facing route in extraEnvVars:
Do not place PLUGIN_AUTH_PUBLIC_BASE_PATH under configmap. The chart accepts that key but does not render it. Use extraEnvVars so the Console receives the value.
The public and server-to-server Auth URLs can point to the same address. In Kubernetes, use the internal service route for server-to-server calls and the public ingress for browser redirects.

​
Configure tenant resolution

Choose one tenant model.

​
Multi-tenant

Set MULTI_TENANT_ENABLED=true. Configure each tenant organization with a tag using the domain: prefix, such as domain:example.com, that Auth must match to user email domains. Do not set a fixed SSO organization in multi-tenant mode.

​
Single-tenant BYOC

Set PLUGIN_AUTH_SSO_STATIC_ORGANIZATION when every SSO request belongs to one fixed organization. Auth then uses that organization before sign-in instead of resolving an organization from a tag with the domain: prefix, such as domain:example.com.
Do not combine PLUGIN_AUTH_SSO_STATIC_ORGANIZATION with MULTI_TENANT_ENABLED=true. Auth rejects this configuration at startup.

​
Expose Auth to the browser

The browser must reach the Auth SSO start route over HTTPS. Configure a public ingress for Auth and allow the Console origin according to your deployment’s cross-origin policy. Identity can remain on a server-to-server route when administrators manage it only through the Console.

​
Configure the identity provider

In the provider application:
  1. Register the exact Console callback URL.
  2. Allow the OpenID Connect scopes required to return the user’s identity and email.
  3. Issue a client ID and client secret for the tenant.
  4. Make the issuer and endpoints reachable from the Access Manager services.
For a Custom OpenID Connect provider, use an issuer that publishes valid discovery metadata. API integrations can instead supply the complete authorization, token, and user-info endpoint set.

​
Validate the deployment

1

Open the Single Sign-On tab

Make sure the Console can read the current provider state from Identity.
2

Run provider preflight

Test the candidate configuration without saving it. Fix every required failure.
3

Register the callback URL

Compare the provider registration with PLUGIN_AUTH_SSO_CALLBACK_URL character by character.
4

Save the provider

Keep password login available during the first test.
5

Test from a private browser session

Enter a tenant email, complete provider sign-in, and make sure the browser returns to the Console.
6

Test tenant isolation

Try an email that does not belong to the tenant. Make sure Auth does not complete the login or reveal tenant details.
7

Test MFA continuation

Sign in with an MFA-enabled user and make sure the Console opens the MFA verification step after SSO.

Configure SSO in the Console

Test and save the provider configuration.