Outbound provisioning to other applications

Inbound provisioning is your directory pushing people into Qorionix. Outbound provisioning is the other direction: Qorionix pushing people out to your other applications, so that a leaver is switched off everywhere rather than only here.

Both are called SCIM and they are entirely separate mechanisms with separate configuration. This article is about the outbound half, and it is short, because there is one thing you need to know about it.

The rest of this article covers what exists, so that you can judge whether to wait for it — and, more importantly, what to do about leavers in the meantime.

What you can configure

GET  /api/v1/organizations/{orgID}/scim/targets     sso.read
POST /api/v1/organizations/{orgID}/scim/targets     sso.write

There is no screen for either. There is also no update route and no delete route, so a target you create is a target you have.

A target takes a name, a base_url, a bearer_token and an attribute_map. The permission family is the single sign-on one, which is the right level — the token you store is a credential that would be able to create and disable accounts in the downstream application.

What the calls would do, if they were called: a create posts a SCIM user object to {base_url}/Users; a deactivate patches the user identified by its external id, setting active to false. Note that the second is a deactivation rather than a delete, which is the correct shape — a hard delete downstream would orphan whatever references the account.

What the integration catalogue now says about this

Until recently the catalogue advertised outbound provisioning on several rows as though you could set it up. It no longer does, and the change is worth understanding because it is the same gap described above, surfaced where people actually look for it.

Nine catalogue entries declare a provisioning capability: atlassian_cloud, aws_iam_identity_center, entra_id, generic_scim, github_enterprise_cloud, gitlab_saas, notion, salesforce and slack. All nine are marked planned and none of them can be configured. The capability filter on the catalogue screen shows this as 9 / 0 — nine rows offer it, zero can be set up.

One row disappeared from the working part of the list entirely. generic_scim offered nothing except outbound provisioning, so with that capability demoted the whole entry became planned. If you had it on a plan as the way we will push accounts anywhere, it never worked; it now says so on its own row.

Where the Configure button used to be, the console prints the reason instead, in full:

What to do about leavers in the meantime

The leaver half is the half that matters. Most organisations create accounts reliably, because somebody is waiting for one; almost nobody removes them reliably, because nobody is waiting for that. An account that still works three months after its owner left is one of the most common findings in a real assessment.

Four things work today and between them they cover most of it.

1. Federate everything you can. A person signed out at your identity provider loses access to every application that federates to it, without anything having to be pushed anywhere. This is the mechanism outbound provisioning is a poor substitute for, and it is available now — see Single sign-on with OIDC. The console says the same thing about it: when someone is disabled at the provider, they lose Qorionix too.
2. Use an inline hook to tell your own systems. qorionix.user.deactivated fires for real and carries the user id and status, signed. It is a notification rather than a guarantee — one attempt, five seconds, no retries — so build the receiving end to be reconciled rather than trusted. Inline hooks.
3. Keep the app assignment list current and use it as the checklist. It grants nothing, but it is the record of which applications a person was entitled to, and an offboarding runbook that works down that list is a working process even though every step is manual. App assignments.
4. Write the runbook and make the last step a verification. Suspend the account, revoke the sessions, revoke any API keys, then go to each application on the list and confirm. User lifecycle and deprovisioning covers what each administrative action here really does — including two that have a wider effect than their names suggest.

When this lands, and what to do now

The honest position: the client is written and the fan-out needs a caller. That is a smaller piece of work than it is a decision — an outbound push that fires on every user change needs a retry policy, a failure surface and a way to tell you a target has been rejecting writes for a week, and none of those exist either.

So the advice is not wait for it. It is: federate what you can, use the assignment list as your manual checklist, and tell us if outbound provisioning is a requirement rather than a preference. Demand is what moves this, and it is genuinely useful for us to know which downstream applications you would point it at.

The one thing not to do is to record in a policy document that Qorionix deprovisions your downstream applications. It does not, and an auditor who tests that statement will find a configured target that has never made a request.