SCIM Provisioning

For self-hosted instances

The Plus Plugin is required!

Seatsurfing supports SCIM 2.0 provisioning so your identity provider can automatically create, update, deactivate, and delete users and groups in your organization.

Supported identity providers include:

• Okta
• Microsoft Entra ID
• Keycloak
• Google Workspace
• Workday
• OneLogin
• PingOne

SCIM provisioning in Seatsurfing is a one-way sync from your identity provider into Seatsurfing. It is intended for user and group lifecycle management only.

What SCIM can do

• Create, update, deactivate, and delete users in your Seatsurfing organization.
• Create, update, and delete groups.
• Add and remove group memberships.
• Reactivate previously deactivated users.

What SCIM does not do

• It does not sync passwords.
• It does not manage spaces, locations, or bookings.
• It does not push changes from Seatsurfing back to your identity provider.
• It does not support SCIM 1.1 or SCIM bulk operations.

Prerequisites

• A Seatsurfing Cloud organization.
• An account that can manage users, roles and service accounts in Seatsurfing.
• An identity provider that supports SCIM 2.0.
• A dedicated Seatsurfing service account, read/write, holding the SCIM permission.

Step 1: Enable SCIM in Seatsurfing

In the Seatsurfing Administration UI, open Cloud Features and enable SCIM provisioning for your organization.

After saving, Seatsurfing shows the SCIM Base URL for your organization. Use this URL in your identity provider's SCIM application.

The SCIM base URL has this format:

https://<your-seatsurfing-domain>/scim/v2/

Step 2: Create a dedicated service account

SCIM authentication uses a Seatsurfing service account API token.

We recommend creating a dedicated service account only for SCIM provisioning:

1. Under Roles, add a role — SCIM Provisioning, say — granting SCIM full access and nothing else. Restricting it this way means the token cannot be used for anything but provisioning.
2. Open the Users section and create a new user with the account type Service Account (read/write), or use an existing dedicated one.
3. Assign the role from step 1 to that service account.
4. Generate an API token for it.
5. Keep the raw token value secure and copy it immediately into your identity provider configuration — it is shown only once.

SCIM requires both: a read/write service account and the SCIM permission. A general-purpose API token cannot drive user provisioning.

The service account is scoped to its Seatsurfing organization, so all SCIM operations only affect users and groups in that organization.

See also: Administration UI

Step 3: Configure your identity provider

In your identity provider's SCIM application, configure:

• SCIM Base URL: your Seatsurfing SCIM endpoint, for example https://<your-seatsurfing-domain>/scim/v2/
• Authentication method: Bearer token
• Bearer token: the raw API token generated for the Seatsurfing service account

Seatsurfing expects the Bearer token on all SCIM requests, including discovery endpoints such as ServiceProviderConfig, ResourceTypes, and Schemas.

Supported provisioning behavior

Users

Seatsurfing maps the following SCIM user attributes:

SCIM attribute	Seatsurfing field	Notes
id	Internal user ID	Generated by Seatsurfing
externalId	External mapping	Stored for the identity provider reference
userName	Email address	Must be unique within the organization
name.givenName	First name	Optional
name.familyName	Last name	Optional
active	User enabled state	active=false disables the user instead of deleting it

Additional attributes such as phone numbers, locale, timezone, title, addresses, or password fields are accepted when sent by the identity provider, but ignored by Seatsurfing.

Groups

Seatsurfing maps the following SCIM group attributes:

SCIM attribute	Seatsurfing field	Notes
id	Internal group ID	Generated by Seatsurfing
externalId	External mapping	Stored for the identity provider reference
displayName	Group name	Required when creating groups
members[].value	Group membership	Must reference Seatsurfing user IDs in the same organization

Deactivation and deletion

When your identity provider sends active=false for a user, Seatsurfing disables that user account instead of deleting it. If the user is activated again later, Seatsurfing re-enables the same account.

A SCIM DELETE request permanently deletes the corresponding user or group in Seatsurfing.

Compatibility notes

Seatsurfing is designed to work with the request patterns commonly used by the supported identity providers. This includes:

• User lookups by email address or external ID.
• User deactivation via SCIM PATCH.
• Group membership add and remove operations.
• Group synchronization requests that omit members for performance reasons.

Unknown or provider-specific attributes are ignored where possible so that provisioning can continue without unnecessary failures.

Security notes

• Use a dedicated service account for SCIM only.
• Only the service account API token is supported for SCIM authentication.
• Regular Seatsurfing login sessions are not valid SCIM credentials.
• Revoking the service account token immediately breaks the SCIM connection until a new token is configured in your identity provider.

Troubleshooting

If provisioning requests fail, check the following first:

• SCIM is enabled in Cloud Features.
• The configured URL ends with /scim/v2/.
• The Bearer token belongs to a read/write service account that has been granted the SCIM permission.
• The service account belongs to the correct Seatsurfing organization.
• The identity provider is sending SCIM 2.0 requests, not SCIM 1.1.

If user provisioning works but sign-in does not, remember that SCIM only manages users and groups. Authentication itself must still be configured separately, for example through Seatsurfing passwords or a supported identity provider login setup.