Provisioned account (SCIM / ConnID)
Authentication is how a user proves who they are at login; provisioning is how the account they log in to comes to exist in the first place. For many tools the login stays local to the tool, but the account behind it is created, updated, and disabled automatically by the platform – so access is governed even when sign-in is not federated.
This is the joiner / mover / leaver lifecycle: when a person is hired, moves role, or leaves, their accounts across connected tools follow, without an operator touching each one.
How ResorsIT integrates it
- SCIM – where a tool implements the SCIM provisioning standard, the platform pushes account and group changes to it directly over that protocol
- ConnID connectors – where a tool has no SCIM endpoint, a connector provisions it instead, run through an on-host agent so the platform can reach targets it could not touch directly (behind NAT, air-gapped, or local-only)
- The platform governs account existence, group membership, and enable/disable; the credential itself is delivered separately (see vaulted credential)
- Each tool page records SCIM support in its SSO facet, alongside OIDC, SAML, and LDAP
Custom provisioning
Not every tool exposes SCIM or has a ready connector. For some apps – both proxy and external – Rhodium may custom-code the provisioning so account lifecycle can still be automated where a standard path does not exist. This is assessed per tool.
If provisioning matters for a tool you rely on, contact Rhodium for details or to discuss a specific tool.
When a tool uses this
Provisioning applies to tools that must have accounts kept in step with the workforce even though users sign in with a tool-local or directory login. It is about the lifecycle of access, and it commonly pairs with another method for the login itself – single sign-on, LDAP, or a vaulted credential.
