Single Sign-On (SSO) Integration

DataGalaxy Portfolio supports integration with OAuth2/OIDC Identity Providers (IdP), enabling the replacement of password-based authentication.
We strongly recommend enabling SSO for all users, as it provides a more secure and centralized way to manage access.

SSO Configuration

To enable SSO with your Identity Provider (IdP), the following steps and information are required.

1. Register a Client in Your IdP

Create a new OAuth2/OIDC client with the following callback URL (adapted to your DataGalaxy Portfolio tenant): https://<tenant name>.yooi.io/auth/sso/callback

2. Provide the Following to DataGalaxy Portfolio Support

1. Authorized email domains: Users with these domains will be allowed to log in via this IdP.

2. Autoprovisioning option:

   • enabled: Authorized users not yet present in DataGalaxy Portfolio are automatically created upon their first login. No administrative action is required to onboard new users in DataGalaxy Portfolio as long as their are authorized by the IdP.

   • disabled: Authorized users must be pre-provisioned in DataGalaxy Portfolio by an administrator; otherwise, they will not be able to log in.

3. Identity provider type: Entra (Azure), Okta or Other.

3. Identity Provider Details

Depending on the provider:

• For Entra (Azure):

  1. Tenant ID

  2. Client ID

  3. Client secret

• For Okta:

  1. Issuer URL, eg https://<okta tenant name>.okta.com

  2. Client ID

  3. Client secret

• For Other:

  1. Either :

     1. The OIDC Discovery .well-known endpoint URL.

     2. Or, the following details:

        1. Issuer

        2. Authorization endpoint URL

        3. Token endpoint URL

        4. User info endpoint URL (if needed)

        5. Jwks URL

  2. Client ID

  3. Client secret

SSO Usage rules and best practices

Mandatory SSO for authorized domains

All users with an email address belonging to an authorized domain must log in via SSO, they cannot authenticate using email/password.

Autoprovisioning behavior

In case autoprovisioning is enabled, the SSO user accounts creation is automatically done, there is no administration task needed.

In case autoprovisoning is disabled, there are many strategies to create accounts:

• Accounts can be created in Admin > Authorization > + Create a new user

• List of accounts emails can be provisioned through Admin > Authorization > Provision SSO users.

• Integrations can also created accounts that are referenced in external data sources.

Test accounts

We strongly recommend not creating test accounts using email addresses outside of authorized domains. These external emails will require password-based authentication instead of using Single Sign-On (SSO), which may disrupt standard workflows.

DataGalaxy Portfolio offers two secure methods for creating test accounts while preserving SSO functionality. These options must be activated by the DataGalaxy Portfolio support team.

Individual Account Aliases

An account alias uses the same base email address with a unique identifier added before the @ symbol. The format is:
<base-email>+<alias>@domain.com

Example:

Main email: john.doe@example.net
Valid alias: john.doe+test@example.net

How it works:

• A separate account must be created using the alias email address (e.g., john.doe+test@example.net).

• When logging in, select Continue with your email (do not use Login with SSO) and enter the alias email address, john.doe+test@example.net for a read-only session, or rw#john.doe+test@example.net for a read-and-write session.

• DataGalaxy Portfolio will authenticate via SSO using the main email (john.doe@example.net) and match it to the alias account.

Behavior:

• Alias accounts function like any other account and can have different permissions and roles.

• ⚠️ Email notifications and automation messages will be sent to the main mailbox (john.doe@example.net), provided the email provider supports aliasing. Otherwise, emails may not be delivered.

Shared Impersonated Accounts

This option allows multiple users to access a test account using their existing credentials via SSO. This configuration must be performed by DataGalaxy Portfolio support. Please provide:

• The alias email address to be used for the test account. This email address must not exist in the SSO directory.

• A list of account email addresses authorized to impersonate the shared test account.

How it works

• Authorized users log in by selecting Continue with your email (not Login with SSO) and entering the email address of the shared impersonated account, prefixed with rw# for a read-and-write session, or without the prefix for a read-only session.

• DataGalaxy Portfolio will authenticate each user via SSO using the user’s main account and grant access to the shared impersonated account.