Copy as Markdown[Open in ChatGPT](https://chatgpt.com/?q=Read%20https%3A%2F%2Fdocs-docusaurus.kinsta.page%2Fuser-guides%2Faccount-management%2Fuser-management%2Fmulti-saml-for-sso.md%20and%20help%20me%20with%20my%20question%20about%20this%20Coralogix%20documentation%20page.)[Open in Claude](https://claude.ai/new?q=Read%20https%3A%2F%2Fdocs-docusaurus.kinsta.page%2Fuser-guides%2Faccount-management%2Fuser-management%2Fmulti-saml-for-sso.md%20and%20help%20me%20with%20my%20question%20about%20this%20Coralogix%20documentation%20page.) # Multi-SAML for SSO Multi-SAML allows you to configure more than one SAML identity provider (IdP) for the same Coralogix scope. Each SAML configuration represents one SSO option that users can select during sign-in. This capability supports enterprises with multiple identity domains, MSPs and MSSPs accessing multiple customer environments, and organizations migrating between identity providers. Multi-SAML also enables staged rollout. You can configure and validate additional SAML providers before making them available to users, allowing controlled migration between identity providers without downtime. For general SAML configuration and setup instructions, see [SSO with SAML](https://docs-docusaurus.kinsta.page/user-guides/account-management/user-management/sso-with-saml/.md). ## Common use cases[​](#common-use-cases "Direct link to Common use cases") Multi-SAML is commonly used in the following scenarios: ### Identity provider migration[​](#identity-provider-migration "Direct link to Identity provider migration") Organizations migrating from one IdP to another (for example, Okta to Microsoft Entra ID) can run both configurations in parallel while users transition gradually. ### Multiple identity domains[​](#multiple-identity-domains "Direct link to Multiple identity domains") Large enterprises may operate multiple identity providers across business units, subsidiaries, or regions. Multi-SAML allows these identity domains to authenticate within the same team. ### MSP and MSSP access[​](#msp-and-mssp-access "Direct link to MSP and MSSP access") Managed service providers (MSPs) and managed security service providers (MSSPs) may need to access multiple customer environments using their own SSO configuration. ## Who manages Multi-SAML[​](#who-manages-multi-saml "Direct link to Who manages Multi-SAML") Multi-SAML configurations are typically managed by: * Team administrators responsible for SSO configuration * Team and organization admins managing authentication policies * Identity and security teams responsible for IdP integrations ## Key capabilities[​](#key-capabilities "Direct link to Key capabilities") Multi-SAML provides several capabilities for managing SSO authentication: * Configure multiple SAML identity providers for the same team * Activate or deactivate individual SSO providers * Allow users to select their SSO provider during sign-in * Support staged identity provider migrations without downtime * Control whether IdP-initiated login is allowed for each configuration ## How Multi-SAML works[​](#how-multi-saml-works "Direct link to How Multi-SAML works") At the team level, you can define multiple SAML configurations under the same team. Each configuration: * Represents one IdP integration * Has its own metadata and settings * Can be set to **Active** or **Inactive** Only active configurations appear as SSO options during sign-in. ### Sign-in behavior[​](#sign-in-behavior "Direct link to Sign-in behavior") If multiple SAML configurations are active for a team, users must select the SSO provider they use to sign in. * If one SAML configuration is active, users can be redirected directly to that IdP after selecting **Log in with SSO**. * If **multiple** configurations are active, users must select which SSO configuration to use during sign-in. * If a configuration is deactivated, it is removed from the available SSO options. ## Organization-level configurations[​](#organization-level-configurations "Direct link to Organization-level configurations") SAML configurations exist at two scopes: * **Team configurations** are created for a single team and available only within it. This page covers team-level Multi-SAML. * **Organization configurations** are defined once at the organization level and assigned to one or more teams, so several teams can share the same identity provider. The two scopes coexist: organization configurations do not replace team configurations, and there is no precedence or override between them. A team's available SSO options are the combination of the organization configurations assigned to it and any team configurations created for it. To set up and manage organization-level SAML, see [Configure organization-level SAML SSO](https://docs-docusaurus.kinsta.page/user-guides/account-management/user-management/configure-org-level-saml/.md). ## SSO sign-in flows[​](#sso-sign-in-flows "Direct link to SSO sign-in flows") Coralogix supports both SP-initiated and IdP-initiated sign-in flows. ### Start sign-in from Coralogix[​](#start-sign-in-from-coralogix "Direct link to Start sign-in from Coralogix") 1. Navigate to the Coralogix sign-in page. 2. Select your team (if prompted). 3. Select **Log in with SSO**. 4. If more than one SSO provider is active, select your SSO provider. 5. Complete authentication in the selected IdP. If only one SSO provider is active, users may be redirected directly to that provider. ### IdP-initiated sign-in (optional)[​](#idp-initiated-sign-in-optional "Direct link to IdP-initiated sign-in (optional)") IdP-initiated sign-in can be enabled or disabled for each SAML configuration. When enabled, users can start the login process directly from their identity provider application tile (for example, Okta or Microsoft Entra ID). Disabling IdP-initiated login prevents unsolicited SAML assertions and requires users to start authentication from the Coralogix login page. In this flow: * The IdP sends a SAML assertion directly to Coralogix. * Coralogix validates that the IdP is configured and authorized for the selected team. * Access is granted only if the configuration is active and valid. Additional authentication protections, such as [multi-factor authentication](https://docs-docusaurus.kinsta.page/user-guides/account-management/user-management/secure_login/mfa/.md), can be configured to further protect user access. ## Manage SAML configurations[​](#manage-saml-configurations "Direct link to Manage SAML configurations") Use the **SAML Configuration** page to: * Add new configurations * Edit existing configurations * Activate or deactivate configurations * Delete configurations * Test configurations A configuration represents one IdP integration and controls whether that IdP is available for SSO sign-in. ## Visibility on the configuration list[​](#visibility-on-the-configuration-list "Direct link to Visibility on the configuration list") The configuration list provides operational visibility into your SSO setup. Depending on your permissions and scope, you may see: * **Status** (Active or Inactive) * **Last modified** timestamp * **Last activated** timestamp * **Never activated** state (if applicable) These fields help administrators understand the current state of SSO configurations. They do not replace centralized audit logs. ## Activate and deactivate configurations[​](#activate-and-deactivate-configurations "Direct link to Activate and deactivate configurations") Activating a configuration does not affect other active configurations. Multiple configurations can be active at the same time, and all active configurations are available as SSO options during sign-in. * **Activate** makes the configuration available as an SSO option during sign-in. * **Deactivate** removes it from the available SSO options. Users cannot log in using a configuration while it is inactive. ## Delete configurations[​](#delete-configurations "Direct link to Delete configurations") Deleting a configuration removes it permanently and makes it unavailable for sign-in. If a configuration is active, it must be deactivated before it can be deleted. Recommended blocker message: Note You can’t delete an active configuration. Deactivate it first, then delete it. ## Create a SAML configuration[​](#create-a-saml-configuration "Direct link to Create a SAML configuration") Adding a configuration opens the **Create SAML Provider** wizard, a guided flow that validates your metadata and surfaces the Coralogix service provider values you need. For provider-specific instructions, see the dedicated SSO integration guides. [![](/assets/images/mult-saml-create-config-f085451cc8859208a7ec416aec0aa841.webp)](https://docs-docusaurus.kinsta.page/assets/images/mult-saml-create-config-f085451cc8859208a7ec416aec0aa841.webp) 1. Select **Add SAML configuration** to open the **Create SAML Provider** wizard. 2. **Provider details** — enter a **Display name** users recognize at sign-in (for example, Okta - Production) and an optional **Description**. 3. **Coralogix service provider details** — copy the Coralogix service provider values (metadata URL, ACS URL, entity ID, binding, and relay state) into your identity provider. 4. **Identity provider metadata** — upload your IdP's **metadata.xml** file by dragging it in or selecting **Upload XML**. 5. **Default groups on first sign-in** — select the default groups assigned to users on their first sign-in. Note Default groups determine the initial roles assigned to users when they first sign in through SSO. For more information, see [Groups](https://docs-docusaurus.kinsta.page/user-guides/account-management/user-management/assign-user-roles-and-scopes-via-groups/create-and-manage-groups/.md). 6. Save the configuration, then activate it when ready. ## What users see when signing in[​](#what-users-see-when-signing-in "Direct link to What users see when signing in") [![](/assets/images/multi-saml-login-dd66ef007e3171e9b185867b1e90c56e.webp)](https://docs-docusaurus.kinsta.page/assets/images/multi-saml-login-dd66ef007e3171e9b185867b1e90c56e.webp) When more than one SSO provider is active for a team: * Users see a provider selection step after selecting **Log in with SSO**. * Each option displays the configuration’s display name. * An optional description may help distinguish providers (for example, “For contractors” or “For corporate users”). Users select the appropriate provider and complete authentication in that IdP. When only one provider is active, the selection step may be skipped. ## Errors and edge cases[​](#errors-and-edge-cases "Direct link to Errors and edge cases") ### No active SSO providers[​](#no-active-sso-providers "Direct link to No active SSO providers") If no SAML configurations are active, users cannot complete SSO sign-in. Use clear guidance such as: Note SSO is not available for this team. Contact your admin or sign in with email and password. Administrators can review and update user access from the Team Members page. To learn more, see [Manage Team Members](https://docs-docusaurus.kinsta.page/user-guides/account-management/user-management/manage-team-members/.md). ### Provider deactivated after prior use[​](#provider-deactivated-after-prior-use "Direct link to Provider deactivated after prior use") If a previously available configuration is deactivated: * Users must select another active provider (if available). * If none exist, SSO is not available. ### Invalid metadata upload[​](#invalid-metadata-upload "Direct link to Invalid metadata upload") If the uploaded file is not valid SAML metadata XML: * Prevent saving the configuration. * Prompt the admin to upload a valid metadata XML file. ### IdP mismatch[​](#idp-mismatch "Direct link to IdP mismatch") If a user attempts to authenticate with an IdP that is not authorized for the selected team: * Block access. * Instruct the user to select a valid SSO provider for that team.