Enterprise sign-in

Each tenant can use local Keycloak accounts or one external OIDC or SAML identity provider. Keycloak brokers the external sign-in; tenant membership and BSQAI permissions remain separate from authentication.

This procedure is for tenant administrators working with their identity-provider administrator. A platform administrator manages tenant creation and email-domain discovery.

Prepare the provider

Use the external provider's discovery document or metadata to obtain the values below. The platform does not periodically import those documents.

Endpoints use HTTPS without embedded credentials, query strings, or fragments. For OIDC, configure a confidential client supporting client_secret_post and PKCE S256. Profile and group claims come from the ID token, not a UserInfo call.

For SAML, configure persistent NameID, POST requests and responses, signed assertions, and RSA-SHA256 requests. The platform accepts one signing certificate at a time; coordinate certificate replacement with the identity-provider administrator.

Provider name, protocol, OIDC issuer and client ID, and SAML IdP entity ID identify the directory and cannot be changed after first configuration. Moving to another directory requires account-migration planning, not reusing the existing provider name.

Configure and verify sign-in

1. Open the tenant's Authentication settings in Administration. During tenant creation, choose External identity provider and enter the protocol details; you can complete credential setup after creation.
2. Save the provider configuration. Copy the generated Callback / redirect URL.
3. Register that URL with the external provider. For SAML, also use the generated service-provider entity ID and Service provider metadata URL to configure the signing certificate. Preserve other applications' existing callbacks and credentials.
4. Enter the OIDC client secret or SAML signing certificate and select Save authentication. Credentials are write-only. A blank replacement keeps the existing value.
5. Wait for the current configuration to report Configured. Resolve any reported credential or provider error.
6. Test the tenant's sign-in flow with an assigned external account in a separate browser session. Confirm the expected tenant and permissions after sign-in.

The generated callback is the external provider's return path to Keycloak, not the Portal application's own redirect URL. Configured confirms reconciliation, not successful authentication against the external provider.

Optional email, first-name, and last-name mappings import profile values on first login only. They do not grant roles, continually update profiles, or automatically link an external identity to an existing local account. Email or username collisions need an explicitly authorized account-linking process.

Discover sign-in by email domain

A platform administrator can enable Discover SSO by email domain and assign one exact domain to one tenant. The platform's Keycloak identity-first flow must be enabled for this routing.

A domain cannot be shared between tenant Organizations. If several tenants use the same email domain, use tenant-specific login links instead. Assigning a domain is an administrative routing decision, not DNS ownership verification.

Existing accounts with local passwords retain local authentication. External-only accounts do not automatically receive a local password, so switching authentication mode is not a guaranteed password fallback.

Synchronize OIDC groups

Group synchronization is available for OIDC providers. It maps exact external claim values to existing ordinary tenant groups; it does not create groups or copy an external directory. SAML group synchronization is not supported.

1. Create dedicated groups under Access Control → Groups and assign their functional roles separately.
2. Return to Authentication and enable Synchronize group memberships.
3. Enter the Groups claim name, normally groups, and add an external value to tenant-group mapping. For example, map engineering to an existing Engineering group.
4. Save, wait for reconciliation, and test a fresh external sign-in with a matching account.
5. Test a nonmatching account and confirm its effective access as well.

Mappings are case-sensitive, not regular expressions. Several external values can grant the same group. Protected administrator groups, operator-managed groups, and groups with protected or incompatible inherited grants cannot be targets.

Membership changes happen at fresh external authentication, not continuously and not on ordinary token refresh. A missing or nonmatching claim removes mapped membership at the next external login, including a manual membership in that same group. Configure the provider to send the complete claim and use separate groups for independently managed access.

Removing a mapping or disabling synchronization stops future updates but leaves existing memberships in place. Review and revoke retained access separately. Group mappings are not an allowed-group restriction on who may sign in.

Change credentials or disable external login

Replace credentials in Authentication, save, wait for reconciliation, and repeat the real sign-in test. Certificate or secret rotation does not change existing user identities.

Disabling the provider retains its registration, linked users, and memberships. It blocks new broker logins but does not revoke existing sessions. If immediate access removal is required, also use the relevant identity and access controls.

Multi-factor authentication

The identity administrator can enforce additional authentication steps, including one-time-password authenticators, through Keycloak or the federated identity provider. Apply the organization’s production identity policy rather than creating a separate weaker policy for the platform.

Development and demonstration clusters

When federation is not configured, an administrator can create a local Keycloak user for testing:

1. Open the Keycloak administration console.
2. Select the dataplatform realm.
3. Open Users and select Create user.
4. Set the username, email, first name, and last name.
5. Add a password on the user’s Credentials tab.
6. Add the user to the required Organization and assign the platform roles needed for the test.

Local users are intended for non-production environments.

Related pages

• Provision a tenant
• Manage members
• Manage groups
• Manage roles and permissions
• Tenant permissions
• System roles