Using multiple identity providers for your Sigma organization (Beta)

🚩

This documentation describes a public beta feature and is under construction. This page should not be considered part of our published documentation until this notice, and the corresponding Beta flag on the feature in the Sigma service, are removed. As with any beta feature, the feature discussed below is subject to quick, iterative changes. The latest experience in the Sigma service might differ from the contents of this document.

Beta features are subject to the Beta features disclaimer.

Sigma supports using multiple identity providers (IdPs) to sign into your Sigma organization, providing greater flexibility for organizations. For example, multiple IdPs can support scenarios where different departments in a company use different IdPs, or where contract and full-time employees use different IdPs.

This document provides an overview of using multiple IdPs, considerations for organizations with existing organization-level OAuth configurations, how to enable multiple IdPs for your Sigma organization, and best practices when using multiple IdPs.

About using multiple IdPs for authentication

Connections that rely on org-level OAuth will no longer function unless updated to use connection-level OAuth. See Considerations for existing organizations using organization-level OAuth.

Enabling multiple identity providers for your Sigma organization

If you would like to enable multiple identity providers for an existing Sigma organization, please contact Sigma support.

Considerations for existing organizations using organization-level OAuth

When you enable multiple IdPs for your organization, you can no longer use existing organization-level OAuth configurations to sign in to connections. If you would like to use the same OAuth application you use for org-level authentication to authenticate into specific connections, you will need to configure this at the connection level.

📘

Configuring a unique OAuth application to authenticate users to a connection – in other words, opting to not re-use the OAuth configuration you use at the organization level – is in public beta.

This documentation describes a public beta feature and is under construction. This documentation should not be considered part of our published documentation until this notice, and the corresponding Beta flag on the feature in Sigma, are removed. As with any beta feature, the feature discussed below is subject to quick, iterative changes. The latest experience in the Sigma service may differ from the contents of this document.

Beta features are subject to the disclaimer on Beta features.

To configure OAuth at the connection level once multiple IdPs have been enabled for your organization:

• For Snowflake connections: See Connect to Snowflake with OAuth. If you would like to use the same OAuth application you use for org-level authentication to authenticate into your connection, you can copy the OAuth Features (such as Metadata URI, Client ID, etc.) being used for the org-level OAuth config.
• For Databricks connections: See Configure OAuth features in Connect to Databricks. If you would like to use the same OAuth application you use for org-level authentication to authenticate into your connection, you can copy the OAuth Features (such as Metadata URI, Client ID, etc.) being used for the org-level OAuth app.

📘

This process should be repeated for every connection you would like to use the OAuth application for.

Best practices when using multiple IdPs

Best practices when using multiple IdPs include:

• When transitioning authentication methods, it is recommended to keep a password-based authentication option enabled. This ensures you aren’t locked out of your Sigma organization if configuration issues arise.
• For organizations using SCIM, ensure that any one user is provisioned by only one IdP at a time. Multiple SCIM provisioning configurations that use the same token are supported, but users should not be provisioned by more than one IdP as this is likely to cause access conflicts.
• Ensure that SCIM provisioning is not used for the same user across multiple IdPs. Users should be provisioned by a maximum of one IdP.
• Organizations with multiple identity providers enabled cannot use organization-level OAuth to log in to connections. You will have to create a unique OAuth configuration at the connection level. See Considerations for existing organizations using organization-level OAuth.