SCIM

SCIM allows you to configure an Identity Provider (IdP) to synchronize users with your Tines tenant.

The Tines API offers a set of SCIM v2-compliant endpoints, documented here.

💡Note

Enabling SCIM 

To turn SCIM on or off for your tenant, go to "Authentication settings" in the settings menu. Note that SCIM is independent from SSO, and is not compatible with Just-in-time user provisioning.

If you enable SCIM for your tenant, users can only be added and modified via SCIM. Regular methods of inviting and modifying users (via the UI or the API) will be disabled and users can only be managed by the Identity Provider.

Configuring your Identity Provider 

In order to configure your Identity Provider to synchronize users with Tines you will need to configure the following:

  • Base URL: https://<<META.tenant.domain>>/api/scim/v2

  • Authorization: Bearer token with an tenant-level API key

  • Unique identifier field for users: userName (note: Tines requires that the userName is the user's email)

Operations 

Supported operations:

  • Provisioning Users and Groups.

  • Pushing Profile Updates.

  • Adding/removing Users from Groups

  • Deprovisioning Users.

    • Note: some Identity Providers may not fully remove users once they are deactivated, destroyed or removed from the application, and instead will mark them as active: false. While these users will no longer be able to access the Tines tenant, a Tenant Owner must delete them via the Tines UI or API to remove their data from the system.

🪄Tip

Attribute mapping 

Refer to the API docs for the list of User attributes supported by Tines.

In order to configure a mapping for users to be granted the "Tenant Owner" role in Tines you can map a field in your user profile to the userType field in the Tines application in your IdP. If you configure SCIM to sync profile attributes, users without this userType will loose their admin privileges.

For example, in Okta, assuming there is an admin field in the User profile, add a mapping from Okta users to Tines of: (user.admin == true) ? 'TENANT_OWNER' : '' → userType

Identity Provider Group to Tines permissions mapping 

🪄Tip

Tenant Owners can configure a mapping between IdP groups and Tines permissiones in the tenant's Authentication Settings. For example, the following would assign users in the Administrators group to be Tenant Owners, and members of several groups to join several teams with different roles.



{
  "tenant_owners_groups": ["Administrators"],
  "mappings": [
    { group_name: "Administrators", team_name: "Analytics", role_name: "TEAM_ADMIN" },
    { group_name: "Managers", team_name: "Analytics", role_name: "TEAM_ADMIN" },
    { group_name: "Managers", team_name: "Incident Response", role_name: "EDITOR" },
    { group_name: "Analysts", team_name: "Analytics", role_name: "EDITOR" },
    { group_name: "Everyone", team_name: "Incident Response", role_name: "VIEWER" },
  ],
}

Mapping Tenant Owners

In the example above, the tenant_owners_groups lists an IdP group that should get promoted to "Tenant Owner" . When tenant_owners_groups is configured, any existing users who are Tenant Owners and do not belong to a group listed here will be downgraded to regular user. Please make sure that group mememberships are being synchronized correctly before making changes to this field. This mapping will also override the userType field, and this field becomes readonly (since the only way to turn a user's userType into "TENANT OWNER" is to assigned them to a group in the list.

Mapping to Tines Teams and Roles

In order for the Idenitity Provider Groups to de mapped onto Tines Teams you need to configure a list of correspondences between IdP groups and Tines Teams via mappings .

Each entry in the mappings array must have a group name field with the name of an IdP group, a team name corresponding to a Tines Team and a role name (VIEWER, EDITOR, TEAM ADMIN, CASE MANAGER or a custom role).

In scenarios where a user is mapped to a team via more than one group, the first applicable entry in the list will be used.

For example:


{
  "mappings": [
    { group_name: "Managers", team_name: "Analytics", role_name: "TEAM_ADMIN" },
    { group_name: "Managers", team_name: "Incident Response", role_name: "EDITOR" },
    { group_name: "Analysts", team_name: "Analytics", role_name: "EDITOR" },
    { group_name: "Everyone", team_name: "Incident Response", role_name: "VIEWER" },
  ],
}

In this case, if a user belongs to the Everyone and to the Managers Groups, they would get the TEAM_ADMIN role in the Incident Response Team since that is stated at the top of the list.

❗️Important

Was this helpful?