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. Our own API for provisioning a tenant's user group mapping is 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 (even though you will probably use the same Identity Provider for both), 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 a 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 full list of User attributes supported by Tines.
In order to grant users 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 lose their admin privileges. Alternatively, you can enable group mapping (see previous section), in which case the userType
attribute is not used.
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
Tines permissions mappings can be managed via our API, documented here.
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 specific 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 (called "Administrators") 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 memberships 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 assign them to a group in the list).
Mapping to Tines Teams and Roles
In order for the Idenitity Provider Groups to be 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 EDITOR
role in the Incident Response team since that is stated at the top of the list.