SCIM (System for Cross-domain Identity Management) automates user lifecycle management for your Gemfury organization. When enabled, your Identity Provider manages organization membership directly — provisioning, deprovisioning, and reactivating users as you assign and unassign them in the IdP.
SCIM is a companion to SAML SSO, not a replacement. SAML handles authentication (logging in); SCIM handles provisioning (managing who has access). Both require an active SAML provider on the organization.
Requirements
- An active SAML SSO provider configured on your organization
- A SCIM Bearer token (see Setup below)
- Administrator access to your Identity Provider
How It Works
SCIM manages organization membership, not user accounts. The lifecycle is:
- IdP provisions a user — When you assign a user to the application in your IdP, it creates a placeholder identity in your organization via SCIM, before the user’s first login.
- User logs in via SAML SSO — Their first login creates or links their Gemfury account, claims the placeholder identity, and joins them to your organization (just-in-time provisioning).
- IdP syncs via SCIM — Your IdP periodically queries the SCIM endpoint to reconcile its member list with Gemfury’s.
- IdP deprovisions a user — When you unassign a user from the application in your IdP, the IdP notifies Gemfury via SCIM. Gemfury immediately removes their organization membership.
- IdP reactivates a user — If you reassign a deactivated user, the IdP restores their membership via SCIM.
What SCIM Does Not Do
- Create Gemfury accounts — SCIM pre-creates a placeholder identity, but the Gemfury account itself is created when the user first logs in via SAML.
- Manage users across organizations — Each SCIM endpoint is scoped to a single organization. A user who belongs to multiple organizations is managed independently by each.
- Provision roles — Roles come from your SAML group mapping (re-synced on every login) or the default role, not from SCIM.
Setup
Step 1: Generate a SCIM Token
- Log in to manage.fury.io and select your organization
- Go to Settings → SSO
- In the SCIM provisioning section, click Generate new SCIM Bearer token
The token is displayed once — copy it immediately. You will not be able to view it again.
Step 2: Configure Your Identity Provider
Enter these settings in your IdP’s SCIM provisioning configuration:
| Setting | Value |
|---|---|
| SCIM Endpoint URL | https://api.fury.io/1/users/ACCOUNT/scim/v2 |
| Authentication Method | Bearer Token (OAuth Bearer) |
| Bearer Token | The token from Step 1 |
Replace ACCOUNT with your organization’s Gemfury username (lowercase).
Step 3: Test the Connection
Most IdPs have a Test Connection button. A successful test queries Gemfury and returns the list of users linked to your SAML provider — both those the IdP has provisioned and those who have logged in. If the list is empty, that’s normal until your IdP provisions users or they log in for the first time.
Token Management
Your SCIM token is shown under Tokens along with other API tokens. The tokens and associated permissions are immutable. However, you can generate multiple tokens and add a human-friendly description.
Deprovisioning Behavior
When your IdP deprovisions a user:
- The user’s organization membership is removed immediately
- Push, deploy, and API tokens owned by the user within the organization are disabled
- The user’s Gemfury account continues to exist — only the organization membership is removed
- The user’s other organization memberships are not affected
Last-owner protection: If the user is the organization’s last remaining owner, deprovisioning will fail. Promote another member to owner before removing the last one.
Supported IdP Operations
Your IdP may perform these SCIM operations against Gemfury:
| Operation | Behavior |
|---|---|
| List users | Returns all users linked to your SAML provider, with their membership status |
| Get user | Returns a single user by ID |
| Create user | Pre-creates a placeholder identity, claimed when the user first logs in via SAML |
| Update user | Stores changes to user attributes; does not affect membership |
| Deactivate user | Removes the user’s organization membership |
| Reactivate user | Restores membership for a deactivated user, at the default role |
| Delete user | Removes the user’s organization membership and SCIM identity |
Deactivate vs. Delete: Deactivation (PATCH) is a soft removal — the user’s SCIM identity is preserved, so your IdP can still query their status and reactivate them later via SCIM. Deletion (DELETE) is a hard removal — the SCIM resource is gone and subsequent queries return not found. Use deactivation for temporary removal.
Troubleshooting
| Error | Cause | Solution |
|---|---|---|
| 401 Unauthorized | Missing, invalid, or revoked token | Regenerate the SCIM token and update your IdP |
| 403 Forbidden | SAML provider is not active | Ensure SAML SSO is configured and active |
| 404 Not Found | Unknown user ID, or a user from a different provider | Verify the user belongs to this organization’s SAML provider |
| 409 Conflict (on deprovision) | User is the last owner | Promote another member to owner first |
Limitations
- Only the User resource type is supported (no Groups); roles come from SAML
- No bulk operations — users are managed individually
- Maximum 100 users per page in list responses