Skip to main content
Version: 11.2

Introduction to SCIM

USoft 11.2

Every application an organisation runs needs to know who its users are and what they are allowed to do. When someone joins the organisation, changes teams, or leaves, that information has to change in all of them at the same time: in the HR system, in the identity provider, and in every application that depends on the identity provider, USoft applications included. SCIM is the standard that lets those systems update each other automatically, and it is what allows the USoft platform to act as a SCIM server.

Background​

SCIM stands for System for Cross-domain Identity Management. It began as an industry response to a problem that every organisation with more than a few applications eventually has: provisioning users — creating, updating and removing their accounts in each application — cannot be done by hand once the number of users and applications grows. Before SCIM, keeping application accounts aligned with the people who actually worked for the organisation meant one of two things: entering the data by hand in each application, or using a connector written for that one application and that one identity provider. Both approaches need a lot of manual work, and both produce errors. Both are also slow, which matters most when someone leaves. If the accounts of someone who has left the organisation are not disabled promptly in every application, that is a security risk, not only an administrative inconvenience.

SCIM standardises the exchange of user information between an identity provider (the system that holds the authoritative list of who your users are, such as Microsoft Entra ID or Okta) and the applications that need to know about them. It defines two things: a common data model for users and groups, and a common REST/JSON protocol for creating, reading, updating and deleting them. Because the model and the protocol are standardised (in RFC 7643 and RFC 7644), an identity provider has to implement SCIM only once. It can then provision any application that supports SCIM, instead of being integrated with each application separately.

How it works (conceptually)​

SCIM defines two roles. The client holds the authoritative user and group data and sends changes to the applications it provisions. The server receives those changes and applies them to its own records. In a SCIM integration with the USoft platform, the USoft platform is the server. Your identity provider is the client: it sends SCIM requests to the SCIM server that has been configured on top of a USoft Rules Service, either on a schedule or in response to events such as a new hire or a role change.

SCIM works like an address format that every postal service has agreed on, rather than a delivery arrangement negotiated separately with each recipient. Without a shared format, every application would need its own instructions for reading a "new employee" or "role change" message. With a shared format, every identity provider writes the message in the same way, and every SCIM server can read it and act on it without work specific to the identity provider that sent it.

Inside the USoft platform, the users and groups that SCIM creates are not held in a separate identity store of their own. A SCIM user is an Application User, and a SCIM group is an Authorizer role — the same objects an administrator would otherwise create by hand in USoft Authorizer. SCIM gives an external system a standard way to create, update and remove them. For exactly how the SCIM attributes map onto Authorizer's tables and columns, see SCIM users and groups.

Why this approach​

USoft implemented the server side of SCIM in the USoft platform, rather than a separate plugin for each identity provider. Because SCIM is a standard, every compliant identity provider sends the same requests, so a single SCIM server implementation works with all of them. Had USoft instead built one plugin per identity provider, adopting a new provider would mean waiting for USoft to add support for it. Once a USoft Rules Service is reachable and configured as a SCIM server, any identity provider that supports SCIM 2.0 can provision users into it, now or in the future, and neither side needs USoft-specific development. See Supported identity providers for the identity providers that USoft has verified this against.

That standardisation is also a constraint. The SCIM data model is deliberately generic, so it does not contain a field for every USoft-specific concept. For that reason, the SCIM server implementation in the USoft platform lets you extend the default schema with extra properties (see Schemas and extension properties), instead of assuming that the standard schema covers everything you need. Your SCIM server also accepts write operations from any client that is configured to reach it. The authentication scheme you choose for it — a shared account with Basic authentication, or a static bearer token — is therefore a genuine security decision, not a formality. See Step 6 of the setup guide for that choice.

Alternatives and comparisons​

SCIM is not the only way that Application Users are created and maintained, and it does not have to be. An administrator can always create, edit and remove Application Users and roles directly in USoft Authorizer, exactly as before. For a small user population that rarely changes, that manual approach may be less work than setting up and maintaining a SCIM integration. SCIM becomes worth the effort as the number of users grows, as people join, move and leave more often, or when removing access quickly changes from something your organisation would like to have into something that a compliance rule requires.

SCIM also solves a different problem from directory-level synchronisation, such as LDAP binds against Active Directory, and a different problem from single-purpose scripts written against a custom API. Directory synchronisation usually works at the level of the whole directory, or of an organisational unit within it, not at the level of an individual application. A custom script must be written, and maintained, separately for each application. SCIM is between these two approaches. It works per application, but it is standardised, so the same identity provider configuration works without change for every application you run that supports SCIM, whether it is a USoft application or not.

One more distinction is worth stating explicitly, because it is easy to confuse the two. SCIM governs provisioning — whether an account exists, what it is called, which roles it holds. It does not govern authentication — how a user proves who they are when logging on. The USoft platform stores SCIM users with Validation Agent = Single Sign On. This means that the USoft platform does not check a password for these users at all. It trusts that the system in front of it has already established who the user is. That system is usually the same identity infrastructure that provisioned the account. See Authentication and the USoft platform for how the various Validation Agents work.

Implications​

Once a SCIM integration is running, the everyday administration of the users and roles it manages moves from USoft Authorizer to the identity provider. A new hire, a team move, or someone leaving is handled in the identity provider, and the matching Application Users and roles in the USoft platform then follow automatically. The work of an administrator on the USoft side changes in the same way. Instead of maintaining accounts from day to day, the administrator keeps your SCIM server running correctly: configured, reachable, and with its log file checked when something appears to be wrong.

This scope is deliberately narrow. Only the users and roles that are linked to SCIM are affected. Accounts that you never provisioned through SCIM — administrative system users, service accounts, database accounts — stay entirely under manual control in USoft Authorizer. SCIM does not see them, and that is intentional. See Only SCIM records are in scope.