WeftID 1.8 pushed lifecycle changes outward: when a user left a group, their downstream accounts went with them. That covers how identity flows from WeftID to your applications. WeftID 1.9 handles the other direction, from your upstream identity providers into WeftID. Provisioning, updates, and deprovisioning now start at the source.
Inbound SCIM ships today with 1.9. It lets WeftID receive pushes from an upstream IdP (Okta or Entra) that create, update, or deactivate user records the moment they change.
Without it, WeftID learns about a user only when they first sign in via SAML or an admin adds them by hand. Accounts that should have been deactivated linger until that next sign-in, and a user cannot be granted app access before they appear. Inbound SCIM keeps the directory in step with the upstream IdP within seconds of any change.
A concrete example:
- You run two apps behind WeftID: Slack and GitHub.
- You connect two upstream IdPs: Entra for your own organization, and Okta for a partner organization.
- You have granted specific Entra and Okta groups access to Slack and/or GitHub.
- When your partner adds an employee to one of those groups, the change flows through the whole chain in seconds: from their Okta into WeftID, and from WeftID on to Slack and GitHub.
- Every step is logged, so you lose no visibility or auditability.
Deprovisioning is a soft-delete, not a destroy. When the IdP sends a DELETE or sets active: false,
the user can no longer sign in, but their MFA enrolment, audit history, and access grants are
preserved. If the upstream account is later re-enabled, WeftID reactivates the same record with the
same access posture. No admin re-grant, no lost history. A user provisioned earlier by SAML
just-in-time becomes SCIM-managed automatically: the first push matching their email merges into the
existing record rather than creating a duplicate.
Both directions run on the same machinery. An upstream change flows through the same event-driven fan-out that admin actions use, so it reaches your downstream SaaS through outbound SCIM with no separate sync step.
Inbound SCIM is configured per IdP, on a tab of the SAML connection it belongs to. Tokens are scoped to that connection and minted in the admin UI; nothing is received until you create one. Day one ships vendor walkthroughs for Okta and Entra, with a spec-correct SCIM 2.0 path for everything else.
The full setup, with per-vendor steps, is in the inbound SCIM admin guide.