Provision workspace users with SCIM

Connect your identity provider (IdP) to Celigo so that it creates workspace users, sets their account-wide access level, and deactivates them when they leave. You turn SCIM provisioning on once per account, give your IdP the base URL and a token, and map one attribute, accessLevel. From then on the IdP manages the people who sign in to integrator.io, and invitations keep working for anyone the IdP doesn't manage.

This article covers the Celigo side of the setup. For how SCIM matches existing users and what it never changes, see SCIM provisioning overview.

Turn on SCIM provisioning

Turning SCIM provisioning on reveals the base URL and the two token slots your identity provider needs. Only the account owner and administrators can do this.

1. Go to Account , and then select Security.
2. On the left side under Company, select SCIM provisioning.
3. Select the SCIM provisioning checkbox. The help text beside it reads Provision, update, and deactivate end users in real time from your IdP.
4. Select Save.

The section now shows SCIM base URL and, under SCIM tokens, two token slots. The base URL has the form https://<your account's host>/scim/v2/workspace-users/{accountId}/, where {accountId} identifies your account. Select the copy icon beside it rather than typing the URL — the host is specific to your account's region, so the URL you copy is the one to use.

Note: The SCIM provisioning section appears only when your subscription includes SCIM and SSO is turned on for the account. If you don't see it, check both.

Generate a SCIM token

Each configuration has two token slots so that you can rotate a token without downtime.

1. Under SCIM tokens, select Generate next to Token 1.
2. Select Copy, and store the token in your password manager. Celigo shows the token once and confirms with the message Token copied to clipboard. Save it now — you won't be able to view it again. After you leave the page, the slot shows only the first characters followed by dots.

Your identity provider sends the SCIM token as an HTTP bearer token:

Authorization: Bearer <token>

A token starts with scim_. Celigo accepts it only with the Bearer scheme. Most identity provider fields take the bare token and add the scheme themselves; a few send the field value verbatim and need you to enter Bearer, a space, and then the token. The setup guide for each identity provider says which kind its field is.

Celigo shows a token once, when you generate it, and stores only a hash. After that, the slot shows the first characters followed by dots. A token works for one configuration only: a workspace token can't provision end users, and an end-user token works only for its identity provider.

Generate into Token 2 only when you rotate. An occupied slot offers Revoke only; after you revoke it, the slot reads Token 1 - No token generated and Generate appears again.

Configure your identity provider

Create a SCIM 2.0 application in your IdP and point it at Celigo. Field names differ by product, and the setup guides in Related articles walk through each one.

1. Create a generic SCIM 2.0 provisioning application, separate from the application that handles SSO sign-in if your IdP requires it.
2. Enter the SCIM base URL as the connector or tenant URL, and the SCIM token as the bearer token or secret token.
3. Map the user attributes listed in the following table, and map accessLevel as described in Map the access level.
4. Turn on provisioning for creates, updates, and deactivations, and leave group provisioning off. Workspace users don't have groups.
5. Assign the people who should have access to Celigo.

On the first synchronization your identity provider pushes everyone at once. Celigo adopts the people it already knows rather than reporting conflicts, and throttles requests per source IP address, so a large initial push takes longer than its size suggests and your IdP retries what it throttled.

Celigo reads the following attributes from a SCIM user and ignores every other attribute, including title, phone numbers, department, manager, employee number, and locale. Leaving those mappings in place in your identity provider does no harm.

Map the access level

The accessLevel attribute sets the account-wide access level, the same setting an administrator picks when inviting someone. Map it to a directory attribute, or derive it from IdP group membership with your IdP's group-to-value rules — members of an IdP group named Celigo-Admins, for example, get administrator.

The accessLevel attribute is single-valued and lives in the urn:ietf:params:scim:schemas:celigo:2.0:WorkspaceUser schema. Celigo also reads it from the top level of the user when the namespace is missing. Values are case-insensitive.

If your identity provider sends nothing or an unrecognized value when it creates a user, Celigo sets none and logs the fallback. On an update, an unrecognized value leaves the current level unchanged. Each push that carries accessLevel sets it, even when nothing changed, so change access levels in your identity provider rather than in Celigo. Celigo never changes the account owner's access level.

none is a value only SCIM sets. It isn't an option when you invite or edit a user in Celigo, it never overrides per-integration grants an administrator made, and in Account > Users the Role cell is empty for a user whose access level is none.

Use none for people who should reach specific integrations only. SCIM can't express per-integration access. Provision the person as none, then grant the integrations in Celigo under Account > Users, exactly as you would for a user with custom access. SCIM never writes per-integration grants, so later pushes of none leave them in place. Sending manage or monitor instead would give the person every integration.

IdP push outcomes

When you assign someone to the application, the IdP pushes them, and Celigo responds in one of three ways. The IdP sees a success in each case.

• The person is new to Celigo. Celigo creates the user and their membership in your account with the pushed access level. They don't receive an invitation. If their email address isn't yet verified with Celigo, they receive the standard Verify your email address email. They sign in with your account's SSO like anyone else.
• The person is already a workspace user in your account. Celigo adopts the existing membership, applies the pushed access level, and marks any pending invitation as accepted. Nothing is removed.
• The person is the account owner. Celigo leaves the owner unchanged and records the request in the audit log. See The account owner is exempt.

The new user appears in Account > Users like any invited user, and nothing marks them as SCIM-provisioned. The audit log holds that history.

Administrators have access to every environment, as they do when invited. To give a Manage all or Monitor all user access to another environment, invite them to that environment in Celigo.

Deactivate and reactivate a workspace user

Unassign the person from the application in your IdP, or disable them there. When the IdP pushes the deactivation, Celigo does the following.

• Disables the person's membership in your account, so they can't sign in to it. In Account > Users, their Enable user toggle is off and their Status stays Accepted.
• Ends their integrator.io sessions. Sessions end in every account the person belongs to, and they can sign back in to the others.
• Revokes the personal access tokens the person created in your account. The next API call with one of those tokens fails.
• Records the change in the audit log with source SSO.

The person's access level and any per-integration grants stay on the record. When the IdP reactivates them, Celigo re-enables the membership with the same access and the person signs in again. Revoked tokens aren't restored.

Note: Deactivation doesn't revoke API tokens. API tokens belong to the account, not to the person who generated them, and stay active. If a departing administrator generated API tokens your automations depend on, review them under Resources > API tokens and rotate or revoke them yourself.

Deleting a person in your IdP is not the same as deactivating them. Celigo rejects a delete request with 501 Not Implemented and leaves the user as they were, so a person deleted before a deactivation reached Celigo stays active. Disable or unassign people first.

The account owner is exempt

Every account has exactly one owner, and ownership moves only through an explicit transfer, so SCIM can't deactivate the owner or change their access level. If your IdP deactivates the owner or sends an accessLevel other than administrator for them, Celigo reports success to the IdP and leaves the owner unchanged, so the IdP's synchronization doesn't fail. Celigo writes an audit entry for each ignored request: deactivate (ownership changes require transfer) or accessLevel:<value> (ownership changes require transfer). The owner appears in the IdP's view of Celigo as an active administrator.

Keep the account owner a shared mailbox that isn't in your directory, such as celigo-owner@yourcompany.com, as Celigo recommends for account ownership in general. Then the IdP never tries to deprovision it, nobody's departure leaves the account without an owner, and the owner keeps a sign-in path if SSO is unavailable.

If the owner is a named person who will leave, transfer ownership before their IdP account is deactivated. Go to Account , and then select Users, select Actions next to the new owner, and select Make account owner. After the transfer, the new owner is exempt from SCIM and the former owner is a regular workspace user whom SCIM manages if the IdP still knows them. Check the Users list after the transfer, and confirm that your IdP's next synchronization completes without errors. See Switch account ownership to another user.

Rotate or revoke a token

1. Go to Account , and then select Security > SCIM provisioning.
2. Select Generate next to the empty slot, the one that reads No token generated, and copy the new token.
3. In your IdP, replace the bearer token with the new one, and confirm in the IdP's provisioning log that pushes succeed.
4. Select Revoke next to the old token. The slot reads No token generated again.

Revoking takes effect at once. If you revoke the only active token, every push fails with an authentication error until you generate a new one and update the IdP.

Turn off SCIM provisioning

1. Go to Account , and then select Security > SCIM provisioning.
2. Clear the SCIM provisioning checkbox, and then select Save.

Celigo revokes both tokens and rejects further SCIM requests. Users the IdP provisioned stay in the account with their current access, and you manage them in Celigo from then on. Turning SCIM back on doesn't restore the tokens — both slots read No token generated, so generate new ones and update your IdP.

Learn more

• SCIM provisioning overview
• Provision end users with SCIM
• Troubleshoot SCIM provisioning
• Set up single sign-on (SSO) for an account
• Manage user roles & permissions to an account
• View or download your audit logs
• Switch account ownership to another user
• Manage API and personal access tokens