Category filter
Configure SCIM Provisioning in Hexnode IdP
This article explains the concepts and architecture of System for Cross-domain Identity Management (SCIM) 2.0 provisioning within Hexnode IdP. It details how Hexnode securely authorizes connections, defines provisioning actions, maps attribute data, and automates the user lifecycle across your enterprise applications.
Introduction to SCIM 2.0 & Application Provisioning
System for Cross-domain Identity Management (SCIM) 2.0 is an open standard designed to automate user identity lifecycle management between identity providers and third-party systems.
While authentication protocols like SAML 2.0 and OpenID Connect (OIDC) manage the “handshake” during a login session, they do not inherently manage the user account’s existence in the application’s database.
- Authentication (SAML/OIDC) answers: Is this user who they say they are, and can they access the app right now?
- Provisioning (SCIM) answers: Should this user exist in the application at all, and what should their profile attributes and group memberships look like?
By utilizing SCIM 2.0, Hexnode IdP ensures that user accounts and group memberships inside target applications remain perfectly aligned with your authoritative central directory.
Application Provisioning in Hexnode IdP
Application provisioning is the process of creating, updating, and disabling user accounts and profiles in target applications (Service Providers). Based on your organization’s configuration, Hexnode IdP supports two methods:
- Automatic Provisioning: When SCIM 2.0 is configured and enabled for an integrated application, Hexnode IdP automatically synchronizes identity data. Actions such as creating, updating, and deactivating user accounts within the target application occur automatically based on a defined schedule and changes within the Hexnode IdP directory.
- Manual Provisioning: If SCIM is not enabled, the integration relies on manual provisioning. IT administrators must manually create, update, and deactivate user accounts directly within the target application’s local database before an SSO login can succeed.
How automatic provisioning works
To successfully automate identity management, Hexnode IdP uses several core mechanisms to establish trust, determine the scope of automation, and translate data schemas.
1. Authorization
To perform lifecycle actions, Hexnode IdP must securely communicate with the target Service Provider’s SCIM API. This trust is established using two primary components:
- SCIM 2.0 Endpoint URL: The base API endpoint exposed by the Service Provider. Hexnode IdP routes all provisioning requests to this specific address.
- Authorization Token: Hexnode IdP authenticates its SCIM requests using a secure bearer token. This token acts as a continuous trust credential. Without it, the Service Provider will reject all inbound provisioning requests from Hexnode IdP.
2. Provisioning Actions
Administrators can define the exact level of control Hexnode IdP exerts over identities inside the target application. You can selectively enable the following operations:
- Create Users: Automatically provisions a new account when a user is assigned to the application in Hexnode IdP.
- Update Users: Synchronizes changes made in Hexnode IdP, ensuring updates to attributes (like name or email) are pushed to the target application over time.
- Deactivate Users: Disables user accounts in the target application when access is revoked or the user is offboarded.
- Sync Groups: Maintains accurate group membership within the application to support role-based access control (RBAC).
3. Attribute Mapping
Different systems often use different naming conventions for data (e.g., Hexnode might use First Name, while the target app expects givenName). Attribute Mapping ensures that identity data in Hexnode IdP aligns with the schema expected by the Service Provider.
- Outbound Directionality: Hexnode IdP supports outbound provisioning. This means Hexnode acts as the authoritative source of truth, pushing data outward to the Service Provider.
- User Attribute Mapping: Administrators map user-level fields (such as First Name, Last Name, Email Address, and Username) from Hexnode IdP to the corresponding fields in the target application.
- Group Attribute Mapping: In Hexnode IdP, a group is simply a collection of users organized by department, team, or role (such as “Sales” or “IT”). The main use of a group is to make access management efficient — allowing you to assign applications to an entire team at once rather than doing it one by one. Group attribute mapping works exactly the same way as user mapping. Instead of matching individual user details, it matches your Hexnode group data with the target application’s group fields, ensuring that team memberships are accurately translated across both systems.
- Customization: Administrators are not limited to the default fields. By clicking the + Add more button, you can manually add and map custom attributes if the target application requires additional data points.
4. Synchronization Schedule
Hexnode IdP does not push identity changes randomly. It evaluates and transmits updates to the Service Provider based on a strict, administrator-defined schedule. This rhythm is controlled by:
- Schedule Frequency: Defines how often the sync cycle occurs (Daily, Weekly, or Monthly).
- Schedule Sync: Defines the exact hour and minute the automated provisioning tasks are executed.
Deprovisioning (Offboarding)
Deprovisioning is the automated offboarding process. When a user leaves your organization, changes roles, or has their application access revoked in Hexnode IdP, leaving their target account active creates severe security vulnerabilities and consumes expensive software licenses.
When a user is unassigned or offboarded, Hexnode IdP triggers a deprovisioning action. During the next scheduled sync, Hexnode IdP sends a structured SCIM request to the target application to disable or remove the user’s account. This prevents future access to the app independent of their SSO login status, ensuring rapid, automated compliance.
In Hexnode IdP, administrators can manually execute global deprovisioning by navigating to Directory > Users > All Users, selecting the target users, clicking Actions, and choose Deactivate User/Delete User action. Depending on the action chosen, SCIM communicates the lifecycle change to the connected applications:
Deactivate User
This action temporarily disables the user’s access without permanently erasing their directory profile.
- Immediate Impact: All active user sessions are terminated instantly, and all valid Refresh Tokens and Access Tokens are revoked.
- Access Restricted: The user is unable to log in to the IdP and all connected applications.
- SCIM Behaviour: A deactivate command is sent to the Service Provider during the next sync to disable the downstream account.
Delete User
This action permanently removes the user from your identity environment.
- Immediate Impact: All access and refresh tokens for the user are revoked instantly.
- Data Erased: All user data, profiles, and historical logs within the IdP are completely purged.
- SCIM Behaviour: Users are fully deprovisioned from all connected SaaS/Cloud applications according to the Service Provider’s deletion logic.
Conclusion: Comparing Provisioning Models
When integrating applications with Hexnode IdP, choosing the right provisioning model is critical for security and operational efficiency. While manual processes or Just-In-Time (JIT) provisioning may suffice for very small deployments, SCIM 2.0 is the only protocol that provides full lifecycle automation.
| Feature | SCIM 2.0 (Automatic) | Just-In-Time (JIT) | Manual Provisioning |
|---|---|---|---|
| Account Creation | Automatic (upon assignment) | Automatic (upon first login) | Manual (IT Admin) |
| Profile Updates | Automatic (via Scheduled Sync) | Reactive (only updates during login) | Manual (IT Admin) |
| Deprovisioning | Automatic (Account disabled/deleted) | Unsupported (Accounts remain orphaned) | Manual (IT Admin) |
| Security Risk | Low (Instant compliance) | High (Orphaned accounts retain access) | Medium (Prone to human error) |
By implementing SCIM 2.0 alongside your SAML or OIDC SSO configurations, you eliminate administrative bottlenecks, drastically reduce the risk of orphaned accounts, and ensure that your application ecosystem always mirrors your central Hexnode IdP directory.
Frequently Asked Questions
What is the difference between SCIM Provisioning and Just-In-Time (JIT) Provisioning?
Just-In-Time (JIT) provisioning creates a user account on the fly the very first time a user successfully authenticates via SAML or OIDC. However, JIT is purely reactive and generally only works in one direction (account creation). It cannot automatically synchronize future profile changes, nor can it deactivate accounts when a user leaves the organization. SCIM is proactive; it continuously creates, updates, and deactivates accounts in the background, regardless of whether the user is actively logging in.
Why are my user profile updates not reflecting immediately in the target application?
Hexnode IdP processes SCIM updates in batches based on your configured Synchronization Schedule. If you update a user’s last name or group assignment, that change will be pushed to the Service Provider at the exact hour and minute specified by your defined schedule frequency (Daily, Weekly, or Monthly).
Does enabling Single Sign-On (SSO) automatically enable SCIM provisioning?
No. SSO (SAML/OIDC) and SCIM are distinct protocols that are configured independently. An application can support SSO without supporting automated provisioning, and vice versa. You must explicitly configure the SCIM endpoint and authorization token to automate the user lifecycle.

