Copy as Markdown[Open in ChatGPT](https://chatgpt.com/?q=Read%20https%3A%2F%2Fdocs-docusaurus.kinsta.page%2Fuser-guides%2Faccount-management%2Fuser-management%2Fconfigure-org-level-saml.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%2Fconfigure-org-level-saml.md%20and%20help%20me%20with%20my%20question%20about%20this%20Coralogix%20documentation%20page.)

# Configure organization-level SAML SSO

Organization-level SAML lets you configure a SAML identity provider once and assign it to multiple Coralogix teams. This reduces duplicate configuration, simplifies administration, and helps maintain consistent authentication policies across your organization.

Organization-level configurations extend [Multi-SAML for SSO](https://docs-docusaurus.kinsta.page/user-guides/account-management/user-management/multi-saml-for-sso/.md). For general SAML setup and provider-specific instructions, see [SSO with SAML](https://docs-docusaurus.kinsta.page/user-guides/account-management/user-management/sso-with-saml/.md).

## Before you begin[​](#before-you-begin "Direct link to Before you begin")

To create or manage organization-level SAML configurations, you must:

* Be an **organization admin** with permission to manage organization-level SAML settings.
* Have an organization with one or more teams.
* Have a supported SAML 2.0 identity provider (for example, Okta, Microsoft Entra ID, Ping Identity, or OneLogin).

Note

Team admins can view the organization-level SAML configurations assigned to their team, but they cannot create, edit, activate, or delete them. They can edit the default groups for their own team.

## How organization-level SAML works[​](#how-organization-level-saml-works "Direct link to How organization-level SAML works")

Organization-level SAML configurations are shared authentication configurations assigned to one or more teams. An organization can have several configurations — for example, a Corporate Okta configuration, a Microsoft Entra configuration, and a partner identity provider — and you assign each one to the teams that use it.

Team-level SAML configurations remain supported and can coexist with organization-level configurations. There is no precedence or override between the two scopes. A team's available SSO options are the combination of the organization configurations assigned to it and any team configurations created for it.

In the following example:

```
Organization

│

├── Organization SAML: Corporate Okta

│   ├── Team A

│   ├── Team B

│   └── Team C

│

├── Organization SAML: Partner Entra

│   ├── Team D

│   └── Team E

│

└── Team-level SAML

    └── Team F only
```

* Teams A, B, and C share the Corporate Okta configuration.
* Teams D and E use the Partner Entra configuration.
* Team F keeps its own independent team-level configuration.

## Create an organization-level SAML configuration[​](#create-an-organization-level-saml-configuration "Direct link to Create an organization-level SAML configuration")

1. Go to **Settings → Account → Configure SAML**. As an organization admin, you manage organization configurations from the **Organization configurations** section of this page.

2. Select **Add SAML configuration**.

3. Configure your identity provider:

   <!-- -->

   * Configuration name
   * Description (optional)
   * Identity provider metadata
   * Coralogix service provider details

4. Set **Apply to** to define the configuration's scope:

   <!-- -->

   * **Apply to organization** — applies to every team in the organization, including teams added later.
   * **Apply to teams** — applies only to the teams you select.

5. If you chose **Apply to teams**, select the teams the configuration applies to. See [Assign configurations to teams](#assign-configurations-to-teams).

6. (Optional) Configure default groups for each assigned team.

7. Save the configuration.

8. Activate it when you're ready to make it available for sign-in.

## Assign configurations to teams[​](#assign-configurations-to-teams "Direct link to Assign configurations to teams")

You assign each organization-level SAML configuration to one or more teams. You can:

* Assign it to **selected teams** to expose it only to those teams.
* Apply it to **all teams** in the organization. Teams added later are included automatically.

Only assigned teams expose the configuration at sign-in. You can add or remove teams at any time. Removing a team makes the configuration unavailable for sign-in to that team; existing users and their permissions remain in place.

## Configure default groups[​](#configure-default-groups "Direct link to Configure default groups")

Groups remain team-scoped, even when a configuration is shared. For each assigned team, you can optionally configure the default groups assigned to a user when they are first provisioned in that team.

For every assigned team, you can:

* Select one or more default groups.
* Apply the same default groups across every assigned team with the **Apply to all teams** option.
* Leave default groups empty if you manage access externally — for example, through [SCIM](https://docs-docusaurus.kinsta.page/user-guides/account-management/user-management/scim/.md) or manual administration.

If you configure no default groups, users can still authenticate, but newly provisioned users might not receive permissions in that team until you grant access through group membership, SCIM, SAML attribute mapping, or manual administration.

Default groups determine the initial roles assigned to users when they are first provisioned in a team. They apply at first provisioning only — if a user was already provisioned another way (for example, through [SCIM](https://docs-docusaurus.kinsta.page/user-guides/account-management/user-management/scim/.md)) and then signs in through SSO for the first time, the default groups are not applied. 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).

## Team view[​](#team-view "Direct link to Team view")

Team admins continue to manage SAML from **Settings → Account → Configure SAML**. The page shows:

* Team-level SAML configurations.
* Organization-level SAML configurations assigned to the current team.

Organization-level configurations are clearly labeled. Team admins cannot edit the configuration itself, but they can edit the default groups for their own team.

## Login experience[​](#login-experience "Direct link to Login experience")

Coralogix supports both SP-initiated and IdP-initiated sign-in.

### SP-initiated sign-in[​](#sp-initiated-sign-in "Direct link to SP-initiated sign-in")

Users start sign-in from a team URL. After they authenticate through an organization-level configuration:

* The user is provisioned according to the configuration.
* Team memberships are created for the assigned teams, subject to provisioning rules.
* The user is signed in to the selected team.

### IdP-initiated sign-in[​](#idp-initiated-sign-in "Direct link to IdP-initiated sign-in")

Users can also start sign-in directly from their identity provider. If the authenticating organization-level configuration is assigned to more than one team, Coralogix prompts the user to select which team to access before completing sign-in.

## Provisioning[​](#provisioning "Direct link to Provisioning")

Organization-level SAML supports Just-in-Time (JIT) provisioning. On a user's first successful sign-in:

* User accounts are created when needed.
* Team memberships are provisioned for the assigned teams.
* Default groups are applied to newly provisioned users where configured.
* Existing users keep their current permissions.

## Permissions[​](#permissions "Direct link to Permissions")

| Action                                         | Organization admin | Team admin               |
| ---------------------------------------------- | ------------------ | ------------------------ |
| View organization-level SAML                   | ✅                 | ✅ (assigned teams only) |
| Create organization-level SAML                 | ✅                 | ❌                       |
| Edit organization-level SAML                   | ✅                 | ❌                       |
| Delete organization-level SAML                 | ✅                 | ❌                       |
| Activate or deactivate organization-level SAML | ✅                 | ❌                       |
| Assign teams                                   | ✅                 | ❌                       |
| Configure default groups                       | ✅                 | ✅ (their team only)     |
| Create, edit, or delete team-level SAML        | ✅                 | ✅                       |

## Best practices[​](#best-practices "Direct link to Best practices")

* Use organization-level SAML whenever multiple teams share the same identity provider.
* Give configurations descriptive names, such as Corporate Okta or Entra Employees.
* Configure default groups for each assigned team so users receive the right permissions on first sign-in.
* If you manage authorization through SCIM or another external process, leave default groups empty and manage permissions externally.

## Frequently asked questions[​](#frequently-asked-questions "Direct link to Frequently asked questions")

### Can I still create team-level SAML configurations?[​](#can-i-still-create-team-level-saml-configurations "Direct link to Can I still create team-level SAML configurations?")

Yes. Team-level and organization-level SAML configurations can coexist.

### Can one organization-level SAML configuration be shared by multiple teams?[​](#can-one-organization-level-saml-configuration-be-shared-by-multiple-teams "Direct link to Can one organization-level SAML configuration be shared by multiple teams?")

Yes. This is the primary purpose of organization-level SAML.

### What happens if I remove a team from an organization-level SAML configuration?[​](#what-happens-if-i-remove-a-team-from-an-organization-level-saml-configuration "Direct link to What happens if I remove a team from an organization-level SAML configuration?")

The configuration is no longer available when users sign in to that team. Existing users and permissions remain in place.

### Can team admins edit organization-level SAML configurations?[​](#can-team-admins-edit-organization-level-saml-configurations "Direct link to Can team admins edit organization-level SAML configurations?")

No. Organization admins manage organization-level configurations exclusively, and the configurations appear as read-only in team settings. Team admins can, however, edit the default groups for their own team.

### What happens if I don't configure default groups?[​](#what-happens-if-i-dont-configure-default-groups "Direct link to What happens if I don't configure default groups?")

Users can still authenticate. However, unless you grant access through existing membership, SCIM, SAML attribute mapping, or manual administration, newly provisioned users might not receive permissions in that team.