SCIM
System for Cross-domain Identity Management (SCIM) lets an identity provider maintain Files.com user accounts and group memberships. A SCIM credential grants administrative authority over provisioning, including every group on its site. Administrators and integration developers need to account for that authority when connecting directories, especially when several identity providers share a site.
User accounts have an association with an SSO configuration; groups organize shared access independently of that association. Separating the two lets a group contain users who sign in through different providers or without SSO. It also means that limiting which user accounts a credential can change does not limit which groups it can manage.
Credentials and Site Scope
Both Basic authentication credentials and bearer tokens authenticate as one SSO configuration and operate on that configuration's Files.com site. They have the same user and group management scope. A credential for one site does not grant SCIM access to another site.
Files.com issues SCIM credentials through the SSO provider's SCIM provisioning settings. Treat them as administrative provisioning credentials: anyone or any system using them receives the scope below. Configuring a second SSO provider on the same site does not create a separate group administration boundary.
User and Group Operations
The SCIM Users and Groups resources apply different rules to existing records.
| Operation | User accounts | Groups |
|---|---|---|
| List and read | Users across the credential's site, including users associated with other SSO providers and users without SSO. | Every group on the credential's site. |
| Create | Creates users associated with the credential's SSO configuration. | Creates groups on the site; the creating SSO configuration does not own them. |
Update with PATCH or PUT | Requires the user to be SCIM-managed through the same SSO configuration as the credential. | Can rename or change membership in any group on the site, regardless of how it was created. |
Deprovision with DELETE | Requires the same SCIM management association. The configured deprovisioning behavior determines whether the account is disabled or deleted. | Can delete any group on the site. Members lose the access supplied by that group; their accounts remain. |
Reading a user does not adopt the account into the credential's SSO configuration. An administrator must associate an existing user with the intended SSO provider before that provider can manage the account through SCIM. User updates or deprovisioning without the required association are refused.
Groups have no equivalent provider association. A group created manually by a Site Administrator and a group provisioned by another SSO configuration are both within the credential's scope. Requests addressed to a group's Files.com id can manage that group without first matching or provisioning it through the credential's provider.
Group Matching
Matching a group during creation serves a different purpose from authorizing changes to an existing group. For POST /Groups, Files.com uses externalId to recognize an existing group on the site. When both externalId and displayName match, Files.com returns that group without applying new attributes or memberships from the create request. If the externalId matches but the name differs, the request returns a conflict.
A matching name alone does not cause a create request to adopt an existing group. Clients use the group's Files.com id for subsequent reads, updates, and deletion. Neither externalId nor the fact that a provider created the group reserves its administration to that provider.
Group Membership and Controls
A group membership request can add or remove users associated with a different SSO configuration, or with no SSO configuration. The normal membership requirements still apply: the user and group must belong to the same site and Workspace, and Partner Users cannot belong to Groups. These requirements are independent of which SSO provider issued the SCIM credential.
Changing membership changes the access supplied by the Group, including folder permissions, configured protocol access, and any Workspace permissions. The user's SSO configuration can also assign administrative roles based on group membership. Evaluate the Group's permissions and the affected users' provisioning rules when deciding who may hold a SCIM credential; its effect is broader than maintaining a directory list.
The setting Allow manual creation, editing, and deletion of groups outside of SSO based provisioning controls manual group management. SCIM requests count as SSO-based provisioning and continue to manage groups when this setting is disabled. The setting does not restrict SCIM to groups originally created through SSO or divide group authority among providers.
The groups selected for synchronization in an identity provider determine its normal provisioning workload. They do not narrow the credential's authority over other groups on the same site. Assign responsibility for maintaining each group when using multiple providers, and use SCIM Logs and Settings Changes to review requests and their resulting changes.