What is SCIM and how does Templafy use it?

What is SCIM?

Templafy supports System for Cross-domain Identity Management (SCIM), which is an industry-standard protocol for automating the exchange of user identity information between different domains or IT systems. The identity provider (ex. Azure AD, OneLogin, Okta etc.) will synchronize your data (identity information) with Templafy which means Templafy will always be up to date with the right user and group information. Hence, if you add or remove an employee from your Active Directory (AD), Templafy will automatically get this information and ensure the right users have access to Templafy.

Prerequisites

NB! Existing users prior to SCIM configuration

Keep in mind that synchronization will happen from the point of configuration, which means all existing users on your Templafy tenant that are deleted from your Identity Provider prior to configuration, will not get deleted on your Templafy tenant after the configuration.

SCIM supported authentication methods

SCIM isn't supported with all authentication methods. For example, ADFS doesn't support SCIM. The known methods that support SCIM are:

• AzureAD
• Okta (Although with limited support since Okta does not perform delete operations on User objects. Hence everything works as expected except do user de-provisioning.)
• OneLogin
• HelloID

Best practices

In the past, we have seen that several non-user objects are being included in the SCIM provisioning (printers, meeting / conference rooms, parking spots, etc.) process by accident. When choosing which Active Directory Group should be used for SCIM provisioning, Templafy recommends the following:

• Create a Dynamic AD Group specifically for Templafy, that will have users added to the group or removed from the group automatically (dynamically populated) based on membership rules . For example, a membership rule can be 'user.jobTitle -ne null' which means that the Dynamic Group will be dynamically populated with users who do not have a blank Job Title field in their AD Profile. This example assumes that conference rooms, printers, parking spaces, etc. do not have Job Titles.
• In our experience we have seen customers use the AD Group used to manage their Microsoft licenses which usually do not contain these non-user objects.