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.

It is not possible to use Teams to grant Organization-level Permissions. Instead, grant Organization-level Permissions by managing group membership within your IdP. Make sure that your IdP group names align with the core patterns for automatic Permission mapping.

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 uses the core pattern to automatically map IdP groups to Cribl Permissions as follows:

• Cribl + a Role name: Map to Organization-level Permissions
• Cribl + Organization + a Role name: Map to Organization-level Permissions
• Cribl + a product name + a Role name: Map to the corresponding product-level Permissions (Cribl Stream and Edge, Cribl Search, or Cribl Lake)

The mapping logic tables for Organization-level Permissions and Product-level Permissions list the valid IdP group names for each Role.

You can add prefixes and suffixes to the core pattern for IdP group names if needed. Cribl’s Permission mapping logic ignores these prefixes and suffixes and bases Permissions only on the core pattern. See examples of valid IdP group names with prefixes and suffixes: Organization-level and Product-level Permissions.

Organization-Level Permissions Mapping Logic

​

The following table lists the valid IdP group names for Organization-level Permissions mapping:

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.

Valid IdP Group Names with Prefixes and Suffixes (Organization-Level Permissions)

​

IdP group names can include prefixes and suffixes as long as they contain the core pattern. Examples of valid IdP group names that include prefixes and suffixes include:

• US Cribl Organization Owner
• Cribl Admin EU
• US Staging Org Cribl Owner-Team B
• CriblOrganizationUserProd

Invalid IdP Group Names (Organization-Level Permissions)

​

Examples of IdP group names that are invalid because they contain hyphens:

• Cribl-Organization-Owner
• Cribl-Owner

Examples of IdP group names that are invalid because they contain underscores:

• Cribl_Organization_User
• Cribl_User

Examples of IdP group names that are invalid because they contain intervening characters that disrupt the core pattern:

• Cribl Org Admin
• Cribl EU Admin

Product-Level Permissions Mapping Logic

​

The following table lists the valid IdP group names for Cribl Stream and Edge Product-level Permissions mapping:

The following table lists the valid IdP group names for Cribl Search Product-level Permissions mapping:

The following table lists the valid IdP group names for Cribl Lake Product-level Permissions mapping:

Valid IdP Group Names with Prefixes and Suffixes (Product-Level Permissions)

​

IdP group names can include prefixes and suffixes as long as they contain the core pattern. Examples of valid IdP group names that include prefixes and suffixes include:

• US Cribl Stream Admin
• Cribl Edge User-EU
• Staging Org CriblSearchEditor-Team A
• CriblLakeReadOnly Prod

Invalid IdP Group Names (Product-Level Permissions)

​

Examples of IdP group names that are invalid because they contain hyphens:

• Cribl-Stream-Admin
• Cribl-Lake-Read-Only

Examples of IdP group names that are invalid because they contain underscores:

• Cribl_Edge_Read_Only
• Cribl_Search_User

Examples of IdP group names that are invalid because they contain intervening characters that disrupt the core pattern:

• Cribl EU Search Admin
• Cribl Stream Dev User

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:

This example shows how groups configuration might look in Microsoft Entra ID: