SCIM Provisioning

SCIM (System for Cross-domain Identity Management) is a standard protocol for automating user and group provisioning between identity providers and applications. Spacelift supports SCIM 2.0, allowing you to automatically sync users and groups from providers like Okta, Microsoft Entra ID, or OneLogin directly into your Spacelift organization.

With SCIM, your identity provider becomes the single source of truth for who has access to Spacelift. When someone joins your company or a team, they're automatically provisioned in Spacelift with the right access level based on their IdP group membership - no need to invite them manually. When they leave the company or move to a different team, their access is automatically adjusted or revoked.

Note

SCIM and SSO determine who can log in to Spacelift, not what they can access. You still need to assign roles before provisioned users can do anything.

Info

This feature is only available to Enterprise plan. Please check out our pricing page for more information.

Prerequisites

• A Spacelift account with admin access
• SSO already configured for your organization.
  • Note that some identity providers only support SCIM for certain SSO types. For example, Okta only supports SCIM for SAML applications, not OIDC.
• An identity provider that supports SCIM 2.0 (Okta, Microsoft Entra ID, OneLogin, etc.)

Setting Up SCIM

Step 1: Generate SCIM Credentials

1. Navigate to Organization Settings > Single Sign-On
2. In the SCIM section, click Activate
3. Copy the client ID and client secret

Warning

Store these credentials securely. The client secret is only shown once. If you lose it, you'll need to reset the credentials, which generates a new client ID and client secret.

Step 2: Configure Your Identity Provider

In your identity provider's SCIM configuration, supply the following:

• Base URL: https://<account-name>.app.spacelift.io/scim/v2
• Authentication type: OAuth 2.0 (client credentials grant)
• Client ID: the client ID from Step 1
• Client Secret: the client secret from Step 1

Your IdP will use these credentials to authenticate against Spacelift's SCIM API and begin syncing users and groups. These credentials are scoped exclusively to the SCIM endpoints and cannot be used to access any other Spacelift functionality.

Assigning Roles

SCIM provisioning creates user and group records in Spacelift, but does not assign any permissions. Users without assigned roles will be denied access when they try to log in.

How you assign roles depends on your management strategy.

Using direct role bindings (Identity Access Management strategy)

With the Identity Access Management strategy, you explicitly bind roles to groups or users. There are a few ways to do this:

Push Groups via SCIM, Assign Roles via Terraform (Recommended)

The best practice is to manage access through IdP groups:

1. Create groups in your identity provider and assign users to them
2. Assign those groups to the Spacelift application in your IdP
3. Configure your IdP to push those groups via SCIM to Spacelift
4. Use the Spacelift Terraform provider to look up the SCIM-provisioned groups with the spacelift_idp_group_mapping data source, then attach roles using spacelift_role and spacelift_role_attachment

DevOps (full admin access)

# This group already exists in Spacelift - provisioned via SCIM
data "spacelift_idp_group_mapping" "devops" {
  name = "devops"
}

resource "spacelift_role" "space_admin" {
  name        = "SpaceAdmin"
  description = "Full admin access to a space"
  actions     = ["SPACE_ADMIN"]
}

resource "spacelift_role_attachment" "devops_root_admin" {
  idp_group_mapping_id = data.spacelift_idp_group_mapping.devops.id
  role_id              = spacelift_role.space_admin.id
  space_id             = "root"
}

Developers (limited access)

# This group already exists in Spacelift - provisioned via SCIM
data "spacelift_idp_group_mapping" "developers" {
  name = "developers"
}

resource "spacelift_role" "run_operator" {
  name        = "RunOperator"
  description = "Can view spaces and manage run lifecycle"
  actions     = ["SPACE_READ", "RUN_TRIGGER", "RUN_CONFIRM", "RUN_DISCARD", "RUN_CANCEL", "RUN_STOP", "RUN_KILL", "RUN_RETRY"]
}

resource "spacelift_role_attachment" "developers_root_reader" {
  idp_group_mapping_id = data.spacelift_idp_group_mapping.developers.id
  role_id              = spacelift_role.run_operator.id
  space_id             = "root"
}

This approach gives you version-controlled, auditable access management that stays in sync with your IdP automatically.

For more details, see Assigning roles to IdP groups.

Assign Roles to Groups via the UI

You can also map SCIM-provisioned groups to roles directly in the Spacelift UI. See Assigning roles to IdP groups for step-by-step instructions.

Assign Roles Directly to Users

If you prefer per-user access control, you can assign roles to individual users. See Assigning roles to users for details.

Using login policies (Login Policy strategy)

With the Login Policy strategy, roles are assigned dynamically at login time based on user attributes like group membership. This is useful when you want policy-driven access control.

For examples how to use login policies, see Login policy examples and Assigning roles to IdP groups using login policies.

Supported Endpoints

All endpoints are served at /scim/v2 and follow the SCIM 2.0 protocol (RFC 7644).

Users

Method	Endpoint	Description
POST	/Users	Create a new user
GET	/Users/{id}	Retrieve a user
GET	/Users	List and filter users
PUT	/Users/{id}	Replace a user
PATCH	/Users/{id}	Update specific user attributes
DELETE	/Users/{id}	Delete a user

Supported attributes: userName (required), externalId, name (givenName, familyName, formatted), emails, active.

userName is used to match users at login

The userName attribute is the most important field. Spacelift uses it to match provisioned users to login sessions from your identity provider. Make sure the userName value in SCIM matches the username or email your IdP sends during SSO authentication. The remaining attributes (name, emails, etc.) are accepted by the SCIM API but are not used by Spacelift - some are stored, others are silently ignored. They do not require specific attribute mapping in your IdP.

Notes on user deletion and deactivation

• Deleting a user (hard-delete) revokes all their active sessions.
• Some identity providers (like Okta or Entra ID) deactivate users (soft-delete) instead of deleting them (hard-delete). When this happens, Spacelift deactivates the user and revokes their sessions, preventing them from logging in. The user record remains in Spacelift and can be reactivated if the IdP reprovisions them later.

Groups

Method	Endpoint	Description
POST	/Groups	Create a new group
GET	/Groups/{id}	Retrieve a group
GET	/Groups	List and filter groups
PUT	/Groups/{id}	Replace a group
PATCH	/Groups/{id}	Update group attributes or members
DELETE	/Groups/{id}	Delete a group

Supported attributes: displayName (required), externalId, members.

Note

• PATCH supports adding/removing members and updating displayName and externalId.
• Deleting a group removes all its member associations.

Discovery

Method	Endpoint	Description
GET	/ServiceProviderConfig	Capabilities and supported features
GET	/ResourceTypes	Supported resource types
GET	/Schemas	Schema definitions

Filtering

Users can be filtered by:

• userName (eq, co)
• active (eq)
• emails (eq, co)

Groups can be filtered by:

• displayName (eq, co)

Example:

GET /scim/v2/Users?filter=userName eq "john@example.com"

Pagination is supported via startIndex and count parameters.

Unsupported Features

The following SCIM features are not currently supported:

• Bulk operations
• Password changes
• Sorting
• Custom schema extensions