Managing users via IdP sync
  • 04 Mar 2024
  • 6 Minutes to read
  • Dark
    Light
  • PDF

Managing users via IdP sync

  • Dark
    Light
  • PDF

Article Summary

Airtable supports SSO for a variety of identity providers (IdP). This article is intended for administrators who are looking to provision/de-provision users and sync user groups with their IdP in the Admin Panel. We are starting with Okta, but we will explore supporting additional IdP in the future.

Prerequisites

Okta provides its own setup documentation related to managing users and user groups. If you are unfamiliar with how these functions work in Okta, then please check out their documentation below:

More information about our Okta app can be found here.

Note

Any existing users who you have already provisioned to use the Airtable app in Okta will need to be re-provisioned after setup in order to take full advantage of the Okta push features for those users. You can run an Okta import for Airtable to do this in bulk.

Okta Features

Push users

There are two important Okta features to consider related to the way that users will sync in Airtable. These are:

  • Push new users - When you create a new user in Okta, Okta will automatically create an account for that user in Airtable.

  • Push user updates - When you update a user’s supported attributes in Okta, it also updates the user’s values in Airtable. Supported attributes include first and last names and fields that only appear in reports, like cost center, department, and division.

  • Push user deactivation - When you deactivate or disable the user's access to Airtable in Okta, this will also deactivate the user in Airtable.

Deactivating a user in Airtable means the user is no longer associated with your Enterprise's Airtable plan. This action will log out all of the user's logged-in sessions. It also means that the user will be greyed-out in any of Airtable's sharing dialogs. To permanently remove the user's account, the admin must either log into the user’s account and delete it through Airtable's interface (in order to transfer out any bases or workspaces owned by that user), or delete the user through the Enterprise API.

Note

We do not charge for deactivated users. So, if there is a chance the user may need to be re-activated (provisioned) in the future, then leaving them in a deactivated state is likely a good practice to follow.

Push groups

This will create an Airtable user group with the same name and membership as the source group from Okta (note that Airtable does not currently support nested groups). Once the groups have been pushed from Okta to Airtable, the Admin Panel supports further changes—it's best to avoid making changes to fields pushed from the IdP (e.g., Group name) as a future sync can overwrite this.

Configuration Steps: Push from Okta to Airtable

In the following scenario, we will be adding a new group in Okta that will push to Airtable causing a new user group to be created in Airtable that matches the group coming from your organization's Okta instance.

Step 1: Check user settings

Your organization may have already set up an integration with the Airtable app in Okta. If this has not been set up yet, then Okta provides a native Airtable integration that can be set up by searching for "Airtable" in their app integration catalog. Look for the app with the "SAML, Provisioning" tag. We will not run you through the full step process of adding this integration as it is covered in Okta's documentation here.

airtable_app_search_okta

Step 2: Check app settings

After connecting Okta and Airtable, you'll want to check the Airtable app integration's settings. From the app's page click Airtable. This will bring you to a window with several tabs. It's worth investigating all of these tabs, but for our purposes, we'll just be looking at the "Provisioning" tab, which allows us to decide whether to enable the "push" toggles discussed above. In our case, we will have these enabled in order to automatically push new users and also sync user activation and deactivation changes made in Okta over to match in Airtable.

okta_app_settings

Step 3: Create a new group in OKTA

If you are unfamiliar with user group creation in Okta, then please refer to their documentation. The simplified version of group creation involves navigating to the "Groups" option under "Directory" and clicking "Add group."

okta_add_group

This will bring up a window to add a group name and optional description. The group name chosen here will sync over to Airtable as that same group name. In this case, we are creating a new group for a "Support" team.

okta_group_name_description

Step 4: Assign group members

After saving the newly created "Support" group, find the group name and click it to open that group's page in Okta. Here you can "Assign People" to the group.

okta_assign_group_members

We are assigning Heather, Cam, and Samuel to this group since they are support team members in our example.

assigned_users_in_okta

Step 5: Assign Airtable app in OKTA

Now, you'll want to assign the Airtable app from earlier steps to this group. From the "Support" group's page in Okta click the "Applications" tab and then "Assign applications." Once the Airtable app has been assigned, the page should refresh and you should see the Airtable app appear in the list.

assign_airtable_application_okta

Step 6: Push group to Airtable

For the last setup step in OKTA, you'll need to head back to the "Applications" page and open the Airtable App. Under the "Push Groups" tab you'll find an option to "Push Groups." Click this to find the group by name or rule.

okta_push_groupsIn this case, we'll find the group by searching for it's name. All that's left is to click the "Save" button at the bottom of the window.

okta_push_find_groupThe group should now appear in the Airtable Application's group list. It may take a moment for the "Push Status" column to change from pushing to "Active."

okta_push_group_active

Step 7: Check Airtable Admin Panel

Once the push status in Okta is Active, navigate to the Admin Panel in Airtable to make further adjustments related to the group as noted in the Groups Admin Panel article—avoid making changes to the fields pushed from IdP (e.g., Group name) as a future sync can overwrite this.

idp_group_in_admin_panel

SCIM metadata

Before moving through the section below, your organization must have already set up Okta to provide SSO and connect to Airtable as highlighted in the sections above. Okta provides its own documentation on how to set up apps to push SCIM data from Okta to an external app using attribute mapping. For user metadata mapping of Airtable fields to SCIM Attributes, see our API documentation. This will allow additional user metadata held in Okta to be displayed in various locations throughout Airtable's Enterprise Admin Panel. Specifically, organizations that use cost centers for accounting purposes will find this feature useful.

After setting up attribute mapping in the Airtable app in Okta, a "Cost Center" field on the Users page of the Airtable Admin Panel will be populated with any cost center data held in Okta.

adminPanelUsersCostCenter04202022

Additionally, if cost center data is available for a user, then it will appear on their individual user details page:

adminPanelUserDetailsCostCenter04202022

Finally, the following information will be available in a CSV export from the admin panel.

  • External ID

  • Title

  • Cost Center

  • Department

  • Division

  • Organization

  • Manager name

  • Manager ID

Here is a redacted image of how that information will appear in the exported CSV:

adminPanelUsersCSVSCIMRedacted04202022

Note

Any additional metadata pushed to Airtable cannot be edited from within Airtable. To edit a user's cost center attributes, you'll need to return to OKTA and change it there.

FAQs

Is cost center data able to be synced to Airtable via SCIM for any other IdP services besides Okta?

We support a subset of the specification for System for Cross-domain Identity Management, or SCIM. We also support a select list of user attributes.

Note

SCIM is only available for ELA & CLAIM enterprises, and SSO is a prerequisite for creating and updating users since we don't allow setting passwords with SCIM. For CLAIM enterprises SCIM can only manage claimed users. More information and a complete list of SCIMP API points are available here


Was this article helpful?