Pulumi Cloud & SCIM

The Pulumi Cloud supports System for Cross-domain Identity Management (SCIM) 2.0 integration with different identity providers. SCIM enables you to manage your users and groups centrally in your Identity Provider (IdP) and then synchronize those users and groups to the Pulumi Cloud.

SCIM provisions two things in Pulumi Cloud:

• Users become members of your Pulumi organization, able to sign in through your identity provider.
• Groups become teams, and group membership becomes team membership. Grant those teams access to stacks, environments, and other entities with RBAC.

Pulumi implements a single SCIM 2.0 endpoint. Every identity provider uses the same routes, schemas, and attributes, so only the IdP-side setup differs from one provider to the next. The guides at the end of this page cover popular providers, and everything documented on this page applies to each of them.

Capabilities

Supported attributes

The lists below are complete. Pulumi implements the core SCIM 2.0 schemas only, so a request that adds or updates any attribute not listed here fails with a 400 invalidPath response. See Unknown path in the troubleshooting guide.

For users:

• userName (immutable after creation, see Usernames cannot change)
• displayName
• name.givenName
• name.familyName
• emails[type eq "work"].value
• active

For groups:

• displayName
• members

What SCIM does not manage

Behavior to plan for

These apply to every identity provider, regardless of which guide you follow.

Provisioned users are managed by your organization

An account SCIM creates belongs to your organization, not to the person using it. Such an account can’t join unrelated Pulumi organizations, connect additional identity providers, or create organizations of its own. See Organization-managed users for the full set of restrictions.

Existing accounts convert in one case only. Someone who already had a Pulumi account and joined your organization by invitation keeps an ordinary account when SCIM starts managing their membership. But the next time your identity provider activates or deactivates such a user, Pulumi checks whether the account can be converted cleanly, and converts it if so. Clean means the user’s personal organization holds no stacks and no environments, and they belong to no Pulumi organization other than yours. An account that fails any of those checks stays ordinary, and the activation change applies as normal.

The conversion is the same operation the user would perform themselves, minus the confirmation: it deletes their personal organization and every login method except your organization’s single sign-on. Someone who signed in with GitHub or Google signs in through your identity provider from then on. See Migrating an existing account.

Deprovisioning never deletes a user

Pulumi has no endpoint for deleting a user through SCIM. Deprovisioning sets active to false, which removes the user’s access to the organization while preserving their account and its history, so the change is reversible by reactivating the user in your IdP. Configure your IdP to suspend or deactivate users rather than delete them.

Teams do not work this way. See Deleting a group deletes the team.

Deleting a group deletes the team

Unlike users, teams are deleted outright. Deleting a group in your identity provider deletes the corresponding Pulumi team, and the access you granted that team goes with it: the team’s roles, and its permissions on stacks and environments. Members themselves are not deleted and remain in your organization.

Two things to plan for:

• The deletion is not recorded in your organization’s audit log, because a SCIM request has no acting user to attribute it to.
• A delete request identifies the team by id, and Pulumi does not check that the id belongs to a SCIM-provisioned team. Any team in the organization can be deleted this way, including one created in the Pulumi Cloud console.

To keep a team while removing its members, empty the group rather than deleting it.

Usernames cannot change

A Pulumi username is immutable once the account exists, because it identifies the user across every organization they belong to. If your IdP pushes a changed userName on an update, the request fails with a 400 immutability response. Map userName so that it applies only when the account is created, not on later updates. Each provider guide covers where to set this.

Group members must already be provisioned

Pulumi validates every member of a group before creating or updating the corresponding team. If any member has not yet been provisioned into your organization, or has been deactivated, the entire request fails with a 400 response and no membership changes are applied. Provision users before pushing the groups that contain them.

Member validation reads up to 3000 identities per request. In an organization larger than that, members outside the window are not silently dropped: they fail validation, and the request is rejected with the same 400 response. This is a practical ceiling on the size of a SCIM-managed team.

Changing the identity provider revokes the SCIM token

Your organization’s SCIM access token is tied to its SAML configuration. If an admin switches the organization to a different identity provider, that configuration is discarded along with the SCIM token, the organization’s SAML identities, and its SAML member roster.

Switching back to SAML doesn’t restore any of it. You have to issue a new SCIM token, point your identity provider at it, and re-provision your users.

Next steps

To set up synchronization between Pulumi and your SAML 2.0 identity provider, refer to one of our example guides:

• Microsoft Entra ID (formerly Azure Active Directory)
• Okta
• OneLogin

For the provisioning errors you are most likely to hit and how to resolve them, see Troubleshooting.