Configuring SSO Groups

When creating an SSO integration with a Cribl.Cloud Organization, configure user groups in your identity provider (IDP) to manage Teams and Members. This enables you to map IDP groups to specific Permissions on all levels.

Link IDP Groups with Teams

​

You can use Teams to automatically connect groups of Members with IDP users. This enables you to grant IDP users Workspace- and Product-level Permissions.

For each Team, you can list one or more IDP group names in the Mapping IDs field. This will automatically grant IDP users in those groups access to that Team’s Permissions.

To create a Team with an external ID, refer to Create a Team. To add an external ID to an existing Team:

1. On the top bar, select Products, and then select Cribl.
2. In the sidebar, select Organization, then Members & Teams, and then Teams.
3. Select the Team you want to configure.
4. In Mapping IDs, provide a list of IDP group names for the Team.
5. Confirm with Save.

Users added to a Team through Mapping IDs will not be listed in the Team Members table. Use your IDP to view the list of Users and manage them.

IDP Group Names and Automatic Permission Mapping

​

If you are not using Teams, IDP group names must include one of the following core patterns:

• Cribl + a Role name
• Cribl + Organization or a product name + a Role name

The core pattern must be a contiguous string, with or without spaces. Cribl’s Permission mapping logic ignores prefixes and suffixes before or after the core pattern in IDP group names.

For example, these are valid IDP group names for Cribl’s mapping logic:

• CriblOwner
• Cribl Owner
• CriblOrganizationUser
• Cribl Search Admin
• dev-CriblOwner
• Cribl Stream User_Test

These are examples of invalid IDP group names for Cribl’s mapping logic:

• ❌ Cribl-Owner
• ❌ Cribl - Admin
• ❌ Cribl_Organization_User
• ❌ dev-Cribl-Owner
• ❌ Cribl Lake_Editor_Test

Permission Mapping Logic

​

If you are not using Teams, Cribl’s Permission mapping logic uses the core patterns to automatically map IDP groups to Cribl Permissions as follows:

• IDP group names that include Organization map to Organization-level Permissions.
• IDP group names that do not include Organization or a product name map to Organization-level Permissions.
• IDP group names that include a product name map to the corresponding Product-level Permissions.

Even though Cribl maps IDP group names that do not include Organization or a product name to Organization-level permissions, we recommend adding Organization to such names for clarity.

The following table demonstrates which Permissions Cribl maps to example IDP group names.

For a more complete list of IDP group names that map to specific Organization- and Product-level Permissions, navigate to Organization > SSO Management in Cribl.Cloud.

Default Product Permissions and Inheritance

​

When you map external users to your Cribl Organization, their initial product-level Permissions follow a different inheritance pattern than Members configured within Cribl. This is to avoid downgrading product-level Permissions that Organization-level Users might already have.

The defaults for mapped users are:

• Organization Owner or Admin inherits Admin Permission on all products.
• Organization User inherits User Permission on all products (except Cribl Lake, which inherits No Access).
• Organization Editor (deprecated) inherited editor legacy Roles on all products.
• Organization Read Only (deprecated) inherited Read Only Permission on Cribl Stream and Cribl Edge, and User Permission on Cribl Search.

Better Practices for Group Naming and Configuration

​

Follow these guidelines for IDP group naming and configuration:

• Use unique names for each group to prevent unintended Permission overlaps. Do not reuse or alias group names.
• Carefully audit and validate group names and mappings. To prevent misconfiguration, make sure to provide the group names verbatim in Mappings IDs.
• Verify your group mappings in a staging environment to prevent pushing misconfigurations to production.
• Set up fallback access before you configure SSO. Define default mappings for IDP users who may not match any Teams you define. This minimizes the risk of orphaned users.
• A Cribl.Cloud Organization’s Owner Role can be shared and transferred among multiple users. This facilitates gradual ownership transfers, corporate reorganizations, and other scenarios. These multiple users should be in both the Owner and Admin groups in your IDP so that they can acquire all needed permissions across Cribl’s two corresponding Roles.
• Aside from dual-assigning the Owners, you should assign every other user only one group in your IDP. Cribl’s Admin and Editor Roles include all the permissions of the Roles below them.
• If only one user is assigned to an Organization’s Owner Role, IDP group updates will not remove the user from the Owner Role. This prevents Owner lockout in case of SSO configuration issues.

Here’s an example of how groups configuration (at an early stage) might look in Okta’s UI: