- 06 Feb 2024
- 12 Minutes to read
Configuring SSO in the admin panel
- Updated on 06 Feb 2024
- 12 Minutes to read
The admin panel is a centralized tool to help Airtable admins manage their organization’s Enterprise account. Learn how to set up SSO logins for your organization.
|Business and Enterprise Scale only
|Web/Browser, Mac app, and Windows app
Using SSO and SCIM in Airtable videos
SSO and Airtable organizations
Single sign-on (SSO) allows users to log in to many websites or apps with one set of login details. This works through connecting with an identity provider (IdP).
IdPs store and manage users' digital identities for digital or cloud-based apps. An IdP can check identities or just provide a list of identities that another service provider (like an SSO) stores. Airtable uses the Security Assertion Markup Language (SAML 2.0) protocol to facilitate connection with SSO IdPs.
In addition to sharing user login credentials with Airtable, IdPs can also create Airtable user accounts on behalf of users. Airtable typically supports Just-in-Time (JIT) provisioning, which means that if a user does not yet have an existing Airtable user account, the IdP will create one for them the first time they access Airtable via SSO.
Airtable also supports System for Cross-domain Identity Management specification (SCIM). SCIM provisioning allows IdPs to pass additional user metadata into Airtable and provision user accounts when users are granted access to Airtable in the IdP. Airtable offers default SCIM integrations for Okta and Microsoft Entra ID. Additionally, customers can build their own custom SCIM integrations for other IdPs.
When SSO is configured for an Airtable organization, its configuration is specific to that domain’s level—which is owned and verified by the parent organization. Suppose an organization has more than 1 domain. In that case, enterprise admins can configure SSO for one, some, or all domains owned by the organization.
Once configured, SSO only manages logins for organization members—which can be set to optional or required. Unmanaged and external users are not subject to an organization's SSO settings.
At a high level, SSO grants users access to Airtable; it does not assign organization user licenses or grant specific organization permissions for workspaces, bases, or interfaces. Managing user licenses and permissions occurs in the admin panel and can’t be controlled via SSO.
Airtable supports both Service Provider (SP)-initiated login and IdP-initiated login, representing the 2 paths a user can take to log into Airtable using Single sign-on.
In SP-initiated logins, users navigate to airtable.com, click Sign in, select the Sign in with Single Sign On, and are redirected to the IdP's signin URL.
In IDP-initiated logins, users navigate directly to their SSO IdP, where they are presented with a list of applications or SPs to choose from. After selecting Airtable, they are logged into their Airtable home screen.
When SSO is first configured for an email domain owned by an organization, the login requirement defaults to optional—meaning that organization members have the option to log in via SSO or email and password.
If the SSO login requirement is set to required, all organization members must log in using SSO. If they attempt to log in any other path, they will be redirected to the SSO sign in URL.
Setting up SSO in the admin panel
After retrieving your organization's third-party SSO metadata, navigate to the admin panel and click on the Settings page in the navigation sidebar on the left. Next, click Security & Authentication.
Next, provide your sign-in url, certificate and, click Save.
The last configuration step is to determine which IdP provider you are integrating with Airtable. Okta and OneLogin configurations will need to be switched to V1 option in the dropdown. Other partner integrations will use the default V2 option.
All that’s left to do now is click Save. This will open a pop-up asking you if you are sure about the changes. Click Save again to allow the SSO login configuration to occur. Changes may take a few minutes to show up.
After clicking save, the Settings page will reload. To log out all users associated with the configured domain and enforce SSO, please navigate back to the SSO & Authentication section and check/uncheck the box under SSO required. Before requiring SSO for your own email domain, you must first log out and back in with SSO to verify that the metadata you've provided is correct.
From here you can also click Edit if future changes are necessary or if you want to delete the configuration.
- If NameID is required, the value must be the user’s email address.
- If NameID format is required, the value can be EmailAddress or unspecified.
- Airtable only allows one set of identity provider metadata per email domain globally. For example, if another enterprise account has configured SSO for a domain (saved sign-in URL and x509 certificate to their admin panel for the domain), subsequent organizations must provide matching information.
Managing rotating SAML certificates
Navigate to Admin Panel, click the Settings option on the left sidebar, then click the Security & Authentication tab. From here, make sure that the domain that you are updating has the SSO required checkbox unchecked.
Click the Edit button under the SSO metadata column, then highlight and delete all of the previous SAML signing certificate, called the x.509 certificate in Airtable.
Access the new x.509 certificate from your IdP. In some cases, this may be referred to as a SAML signing certificate within the IdP that your organization uses. You'll want to copy this certificate for use in the next step.
Paste the contents of the new certificate that you just copied into the x.509 field in the metadata configuration window of the admin panel. This information should already be blank after following Step 2. Click Save after pasting the content. After editing your IdP metadata, the changes may take up to 5 minutes.
Recheck the SSO required option. In some cases, your organization may leave this off, in which case, you can skip this step.
Troubleshooting SSO error messages
“I changed a user's email address in the IdP and now they can't see any of their workspaces, bases, or interfaces.”
- For SSO configurations using Just-in-Time (JIT), it is necessary to first update the user account’s email address in Airtable via the "User details" page of the admin panel or the Enterprise API (API documentation) before updating the email address in the user’s profile in the IdP.
- If a duplicate account was created because the email address was updated in the IdP first, you can take the following steps to rectify the issue:
- For SSO configurations using SCIM provisioning, emails can be updated on the IdP side, which will update the email address attribute of the associated Airtable user account.
“SAML Certificate Signature Check”
- This error message indicates that the x.509/SAML certificate stored in your enterprise account’s admin panel under “SSO metadata” does not match the x.509/SAML certificate currently supplied by your IdP.
- To resolve this error, admins must update the x.509/SAML certificate with the correct one from your IdP. See the “Managing rotating SAML certificates” section for instructions.
"SSO isn’t set up for your account”
- This error message may indicate any of the following scenarios:
- Your Airtable user account is an unclaimed member of an SSO-configured organization.
- The email address associated with your Airtable user account does not match any domains owned by the SSO-configured organization.
- You haven’t been granted access to the Airtable application on the side of your organization’s IdP.
"403 app not assigned" or something similar
- Errors like these indicate the user hasn’t been granted access to the Airtable application on the side of your organization’s IdP.
- To resolve this, please get in touch with one of your organization’s enterprise admins or your organization’s IT department to request that your user profile be granted access to Airtable in your IdP.
|Single Sign-On (SSO)
|Single sign-on (SSO) allows users to log in to many websites or apps with one set of login details. This works through connecting with an identity provider (IdP).
|Identity Provider (IdP)
|An identity provider stores and manages users' digital identities for a digital or cloud-based app. An IdP can check identities or just provide a list of identities that another service provider (like an SSO) stores.
|Service Provider (SP)
|A Service Provider (SP) refers to a company or organization that offers services to customers or clients. In the context of technology or telecommunications, an SP typically provides services like internet connectivity, cloud computing, or managed IT solutions.
|Security Assertion Markup Language (SAML)
|Security Assertion Markup Language (SAML) is an XML-based framework used for exchanging authentication and authorization data between different systems. It allows users to log in once to access multiple applications without the need for separate usernames and passwords.
|Just-In-Time provisioning (JIT)
|Just-In-Time (JIT) provisioning refers to the process of granting access to resources or services to users only when they need it, and for the duration they require it. It ensures that users have the necessary permissions and privileges at the right time, reducing the risk of unauthorized access and improving security.
|System for Cross-domain Identity Management (SCIM)
|System for Cross-domain Identity Management (SCIM) is a standardized protocol that simplifies the management of user identities across different systems and domains. It allows for seamless user provisioning, de-provisioning, and synchronization of user data between various applications and directories.
|SP-initiated SSO, or Service Provider-initiated Single Sign-On, is a method that allows users to access multiple applications or services with just one set of login credentials. Instead of logging in separately to each application, users can authenticate themselves once with the service provider and gain access to all the connected applications seamlessly.
|IdP-initiated SSO, or Identity Provider-initiated Single Sign-On, is a process that allows users to access multiple applications or services using a single set of login credentials. Instead of logging in separately to each application, the Identity Provider takes the lead by initiating the authentication process and securely sharing the user's identity information with the desired applications.
|An X.509 certificate is a digital document that serves as a form of identification on the internet. It contains information about the identity of an entity, such as a website or an individual, and is used to establish secure communication over a network.
|SSO metadata, short for Single Sign-On metadata, is a set of information that allows different systems to communicate and authenticate users seamlessly.
In the admin panel, SSO metadata refers to the IdP's sign-in URL and x.509/SAML certificate.
In the context of technology or computer science, domains refer to a specific area or subject matter. It represents a distinct field of knowledge or expertise within which certain rules, concepts, and terminology are applicable.
An attribute refers to any metadata associated with a user's profile in the IdP and/or the SP, including username, department, and cost center. For a list of user attributes (or fields) supported by Airtable's SCIM user object, see our API documentation.
Assigning and managing user licenses via your SSO IdP is not currently supported.
Assigning and managing collaborator permissions on enterprise workspaces, bases, or interfaces via your SSO IdP is not currently supported.
Airtable supports out-of-the-box SCIM integrations for Okta and Microsoft Entra ID.
With developer support, enterprise customers can build custom SCIM integrations via the Enterprise API for their organization, regardless of membership claim setting. See this API documentation for more information.
With Just-in-time provisioning (JIT), user accounts are created when a user attempts to access Airtable using SSO. With SCIM provisioning, user accounts are created once granted access to the IdP.
SSO login requirements apply only to organization members. Unmanaged users and external users are not subject to an Organization’s SSO settings.
Airtable only allows one set of identity provider metadata per email domain globally. If another enterprise account has already configured SSO for a domain (saved sign-in URL and x509 certificate to their admin panel for the domain), subsequent organizations must provide matching information.
Some IdPs require separate Entity IDs to establish multiple instances of the Airtable application inside a single tenant. Airtable does not offer unique Entity IDs. Instead, we recommend managing different groups inside a single instance and sharing the SSO metadata.
We support programmatic disabling/re-activating users via SCIM for Okta (and only Okta). For additional details and setup instructions, please read our support article.
Update user email addresses in the Admin Panel using these instructions and then have them sign into Airtable using their IdPs. After signing in, users should see their updated workspaces/bases and email addresses on the home screen.
In Airtable, our system expects Enterprise Scale accounts using shared domains—domains federated to multiple Enterprise accounts—to use the same SAML metadata for SSO. What this means is that if your company has existing Enterprise ScALE accounts with SSO configured, you will need to coordinate with the admins (or IT department) of the other accounts to obtain the current sign-in URLs, x.509 certificates, and ensure that your users have the necessary access to the Airtable tenant present in your company’s identity provider.
You can configure separate tenants or identity providers for domains unique to Enterprise Scale accounts, as each domain can be configured with its own SAML metadata.