SCIM Provisioning: Waarom De-provisioning het Onderdeel is dat Iedereen Verkeerd Aanpakt

Wat SCIM daadwerkelijk is

SCIM staat voor System for Cross-domain Identity Management. Het is een open standaard — schema in RFC 7643, protocol in RFC 7644 — die een REST API definieert voor het uitwisselen van identiteitsgegevens tussen systemen. Versie 2.0 is wat elke grote IdP implementeert.

Het mentale model is eenvoudiger dan het acroniem. Je IdP is de client, de downstream applicatie is de server. De IdP beheert een lijst van personen en groepen, en wanneer die lijst verandert, voert deze een HTTP-call uit om dat door te geven.

SCIM definieert twee resource-verzamelingen, en het gehele protocol draait om deze twee:

En de lifecycle komt overeen met reguliere HTTP-verbs:

De een-na-laatste rij is de belangrijkste. SCIM heeft een gestandaardiseerde, eersteklas manier om aan te geven dat deze persoon geen toegang meer mag hebben — en dat signaal ontstaat waar het vertrek van iemand al is vastgelegd: de door HR gevoede identiteitsbron, niet een spreadsheet van de IT-afdeling.

SCIM is geen SSO, en het verschil is essentieel

SSO beantwoordt een vraag tijdens het inloggen: is deze persoon op dit moment wie hij of zij beweert te zijn? Er arriveert een SAML-assertion of een OIDC-token, de applicatie valideert deze en de sessie begint.

SCIM beantwoordt continu een vraag: hoort deze persoon hier überhaupt te bestaan? Het draait op een eigen schema, onafhankelijk van het feit of iemand inlogt.

De kloof tussen die twee is de kern van het probleem. Als je SSO draait met alleen just-in-time accountcreatie, bewaakt je IdP de voordeur terwijl de accounts erachter zich voor altijd opstapelen. Het deactiveren van iemand in de IdP blokkeert weliswaar nieuwe logins, maar het account-object blijft bestaan — inclusief alle toegewezen rollen, lidmaatschappen en (en dat is extra pijnlijk op een AI-platform) alle verzamelde API-sleutels en service-tokens.

Waarom de-provisioning het onderdeel is dat iedereen verkeerd aanpakt

Onboarding is een opvallende fout. Offboarding is een stille fout. Die asymmetrie verklaart vrijwel elke bevinding bij toegangsaudits die we ooit hebben gezien.

Niemand klaagt over toegang die ze niet zouden moeten hebben. Wanneer provisioning mislukt, stuurt een nieuwe engineer binnen twintig minuten een bericht in een kanaal. Wanneer de-provisioning mislukt, heeft de betrokkene het pand al verlaten. Er is geen feedbackloop, dus de fout blijft bestaan totdat een auditor op onderzoek uitgaat.

Handmatige offboarding-checklists verouderen. De checklist wordt geschreven wanneer het bedrijf acht SaaS-tools gebruikt. Twee jaar later zijn dat er zestig, maar de checklist bevat er nog steeds acht.

De verblijftijd is lang. Omdat niets het probleem aan het licht brengt, blijven zwevende accounts vaak maandenlang onopgemerkt bestaan. Ze komen pas boven water tijdens een audit of een incident — precies de twee slechtste momenten om ze te ontdekken.

Op AI-platformen is een verweesd account meer dan alleen een login. Een verouderd gebruikersrecord kan gekoppeld zijn aan credentials van model providers, MCP-servertoegang, ingezette workloads en langdurige API-sleutels. Browsersessies verlopen vanzelf, maar programmatic credentials niet. Dit is waarom API-authenticatie en RBAC in een AI-gateway identiteitsbewust moet zijn in plaats van sleutelbewust — een sleutel zonder eigenaar is een sleutel die niemand ooit zal intrekken.

SCIM elimineert de menselijke stap. Het vertrek wordt eenmalig vastgelegd in de IdP en wordt automatisch naar buiten toe doorgevoerd.

SCIM vs JIT vs invite-only: welke provisioning-modus te gebruiken

TrueFoundry ondersteunt drie provisioning-modi, en een tenant gebruikt er exact één tegelijk. Dit is de beslissing die de meeste teams proberen te nemen wanneer ze zoeken naar SCIM.

Hieruit komen drie inzichten naar voren.

JIT is geen lichte variant van SCIM. Het is de helft van SCIM — de zichtbare helft. Het regelt uitstekend en zonder configuratie dat een nieuwe medewerker een account krijgt. Het doet echter niets wanneer iemand vertrekt. Als je voor JIT kiest met de gedachte "we regelen offboarding wel handmatig", leg dan eerlijk vast wie die stap beheert en hoe deze wordt geauditeerd.

Invite-only is geen slechtere optie, het is een andere optie. Voor een externe contractor bij een partnerbedrijf die niet in je IdP staat, is een uitnodiging het juiste mechanisme. Het probleem ontstaat wanneer je dit gebruikt voor medewerkers die wel in je IdP staan, omdat je beheerders dan een handmatige kopie worden van een systeem waar je al voor betaalt.

Groepssynchronisatie is de rij die vaak wordt onderschat. Het automatisch aanmaken van gebruikers bespaart een paar minuten per nieuwe medewerker. Het synchroniseren van groepen is wat de autorisatie op de lange termijn correct houdt — een terugkerende besparing in plaats van een eenmalige.

Waar teams de mist in gaan

SSO behandelen als de-provisioning. De meest gemaakte fout, en een begrijpelijke, omdat het uitschakelen van een gebruiker in de IdP nieuwe logins blokkeert. Wat het echter niet doet, is het account, de groepslidmaatschappen of de bijbehorende credentials verwijderen. De voordeur blokkeren is niet hetzelfde als het account opheffen.

Groepsnamen die stilzwijgend niet synchroniseren. Elk provisioning-systeem heeft naambeperkingen, en IdP-groepen worden meestal benoemd door mensen die die regels nooit hebben gelezen. Een groep genaamd ML Platform — Prod (EMEA) bevat spaties, een kastlijntje en haakjes, en zal downstream geen geldig team worden. De fout treedt stilzwijgend op: gebruikers worden gesynchroniseerd, de groep niet, en niemand merkt het op totdat iemand vraagt waarom het team leeg is.

Aannemen dat SCIM elke toegewezen recht van een persoon bereikt. SCIM synchroniseert gebruikers en groepslidmaatschappen. Het weet niets van rechten die rechtstreeks — buiten een groep om — op een specifieke resource zijn verleend. Als je iemand uit een team verwijdert, blijft de directe toewijzing bestaan. Dit is de meest voorkomende oorzaak van de vraag "waarom kan deze persoon dat nog steeds zien?".

De SCIM-token slecht of niet opslaan. De Bearer-token wordt slechts één keer getoond. Teams plakken deze in de IdP, sluiten het tabblad en bewaren geen kopie. Dat is te overzien — je kunt een nieuwe genereren — maar daardoor vervalt de oude token, waardoor de provisioning stopt totdat de IdP ook is bijgewerkt. Sla de token op in je secret manager voordat je het tabblad sluit.

Wil je de lifecycle van begin tot eind bekijken?

Start een TrueFoundry-tenant, koppel je IdP en zie hoe een groep automatisch een team wordt.

Gratis aan de slag

Hoe SCIM-provisioning werkt in TrueFoundry

TrueFoundry ondersteunt SCIM voor zowel OIDC- als SAML v2 SSO-configuraties. Voordat je provisioning configureert, moet SSO werken — de SCIM URL en token bevinden zich naast de SSO-configuratie, niet in een afzonderlijke integratie.

Stap 1 — SSO configureren

Ga naar Platform → Settings → SSO, zet de schakelaar op Enabled, kies je provider en selecteer OIDC of SAML v2.

Voor OIDC geef je een Client ID, Client Secret en Issuer URL op; de callback URL aan de IdP-zijde is altijd https://login.truefoundry.com/oauth2/callback. Voor SAML geef je de IdP SSO URL en een X.509-ondertekeningscertificaat op. Na het opslaan haal je de door TrueFoundry gegenereerde Callback URL en Issuer op en plak je deze in je IdP.

Een detail dat later tijd bespaart: configureer je IdP om claims uit te sturen met de namen email, sub en groups. Dat zijn de standaardwaarden van TrueFoundry, en door de attributen aan de IdP-zijde te aliassen hoef je de geavanceerde velden nooit aan te raken.

Stap 2 — SCIM inschakelen

Ga naar Settings → Security & Access → Provisioning en selecteer SCIM. Dit is de plek waar alle drie de provisioning-modi zich bevinden. Door er een te kiezen, bepaal je het lifecycle-model van de tenant.

Stap 3 — Kopieer de SCIM Base URL

Vouw je opgeslagen SSO-configuratie uit om de SCIM URL samen met de overige metadata te tonen. Dit is de waarde die je IdP aanroept.

Stap 4 — Genereer de SCIM-token

Klik op het sleutelicoon naast de SSO-configuratie om de SCIM-authenticatietoken te genereren.

Behandel deze token als een wachtwoord. Deze wordt alleen getoond bij het aanmaken; als je hem verliest, moet je een nieuwe genereren waardoor de vorige token stopt met werken.

Stap 5 — Koppel je IdP

Stel in de provisioning-instellingen van je IdP de Base URL (sommige IdP's noemen dit Tenant URL) in op de SCIM URL, stel Authentication in op Bearer Token en plak de SCIM-token als tokenwaarde. Wijs vervolgens gebruikers en groepen toe in de IdP en start de provisioning. Binnen enkele minuten verschijnen gebruikers en teams in TrueFoundry.

IdP-groepen worden teams — dit is het onderdeel dat er toe doet

De meeste artikelen over SCIM stoppen bij gebruikerssynchronisatie. Gebruikerssynchronisatie is de makkelijke helft. De reden om SCIM te draaien op een platform als dit is groepssynchronisatie, omdat autorisaties gekoppeld zijn aan groepen.

Wanneer de tenant is geconfigureerd voor SCIM, wordt elke groep die je IdP doorgeeft automatisch een TrueFoundry-team. Voeg iemand toe aan de IdP-groep en deze wordt lid van het team; verwijder de persoon en het lidmaatschap vervalt.

Gesynchroniseerde teams zijn in elk ander opzicht gewone teams. Je kunt ze toegang verlenen tot resources, rollen op tenant-niveau toewijzen en claim-mappings van de identity provider toevoegen.

Wees nauwkeurig over de taakverdeling. SCIM bepaalt niet wat een team mag doen — een beheerder verleent het team eenmalig en bewust de bijbehorende rollen. SCIM automatiseert het lidmaatschap. Omdat rechten aan het team zijn gekoppeld, betekent een actueel lidmaatschap direct een actuele set van rechten. Ontwerp de autorisatie één keer; laat de IdP de personeelswisselingen afhandelen.

Er is een naambeperking om rekening mee te houden. De naam van de IdP-groep wordt de teamnaam, wat betekent dat deze alleen alfanumerieke tekens, koppeltekens en underscores mag bevatten, en maximaal 36 tekens lang mag zijn. Hernoem groepen in de IdP voordat je provisioning inschakelt, niet er na.

Een praktijkvoorbeeld: een contractor in het ML platform team

Hier is de volledige lifecycle van begin tot eind, met de handmatige stappen gemarkeerd.

Eenmalige instelling (handmatig). Een beheerder maakt een IdP-groep aan genaamd ml-platform-contractors — kleine letters, koppeltekens, 23 tekens, veilig. SCIM pusht deze en er verschijnt een team met dezelfde naam in TrueFoundry. De beheerder verleent dat team wat nodig is: het betreffende model provider-account, User-toegang op twee MCP-servers, verder niets. Dat is het autorisatie-ontwerp, eenmalig uitgevoerd.

Onboarding (automatisch). Een contractor begint. HR-provisioning voegt de persoon toe aan ml-platform-contractors. SCIM maakt de TrueFoundry-gebruiker aan en voegt deze toe aan het team. De contractor logt in via SSO met precies de toegang die het team heeft. Niemand hoefde een ticket in te dienen.

Wijziging van werkzaamheden (automatisch). Na drie maanden stapt de contractor over naar een ander project. Iemand verwijdert de persoon uit ml-platform-contractors en voegt deze toe aan een andere groep. SCIM past beide teams aan. De toegang tot de model provider verdwijnt automatisch met het teamlidmaatschap, zonder dat een beheerder TrueFoundry hoefde te openen.

Offboarding (automatisch). Het contract loopt af. Het IdP-record wordt gedeactiveerd. SCIM markeert de TrueFoundry-gebruiker als inactief, en een gedeactiveerde gebruiker wordt geweigerd tijdens de authenticatieflow. Het account werkt niet meer, zonder dat iemand eraan hoefde te denken dat TrueFoundry op de offboarding-lijst stond.

Het enige dat nog handmatig is. Als die contractor ook rechtstreeks toegang had gekregen tot iets — bijvoorbeeld een losse secret-groep buiten een team om — blijft die toewijzing bestaan, omdat deze nooit vanuit de IdP is gekomen. De deactivering blokkeert de inlog sowieso, maar het toegangsrecord blijft aanwezig totdat iemand het verwijdert. Neem dit op in je periodieke toegangscontroles. Dit is hetzelfde patroon dat terugkomt bij enterprise MCP access control: overgeërfde en directe rechten combineren, en het verwijderen van de een verwijdert de ander niet.

Klaar om je IdP de bron van de waarheid te maken?

Configureer SSO, schakel SCIM in en laat groepslidmaatschap de toegang sturen.

Start gratis op TrueFoundry

Aandachtspunten om te weten

Voor Entra ID en Okta vereist SCIM SAML. In de algemene functionaliteitsmatrix staat SSO slechts als aanbevolen voor SCIM, maar voor de twee meest gebruikte IdP's zijn de provisioning-handleidingen afhankelijk van de SAML-configuratie. Als je OIDC instelt met Entra of Okta en daarna SCIM wilt toevoegen, zul je de reconfiguratie opnieuw moeten uitvoeren.

Eén provisioning-modus per tenant. Je kunt niet binnen dezelfde tenant SCIM draaien voor medewerkers en invite-only voor contractors door beide knoppen om te zetten. Als je iemand moet toevoegen die niet in je IdP staat, bestaat de Invite User-flow op Access > Users nog steeds — en wanneer je deze gebruikt voor een SSO-gebruiker, laat je het vakje Send email to set password uitgeschakeld, aangezien er geen wachtwoord hoeft te worden ingesteld.

Deactiveren en verwijderen zijn verschillende acties. Deactiveren blokkeert de login en is wat SCIM uitvoert. Het definitief verwijderen van een gebruiker is een afzonderlijke beheerdersactie, en TrueFoundry weigert dit totdat de gebruiker expliciet is verwijderd uit alle resources en teams. Deze beveiliging voorkomt dat je een identiteit verwijdert terwijl er nog zwevende toewijzingen naar verwijzen.

De toegewijde Provisioning-pagina is geïntroduceerd in v0.143. In eerdere versies werd SCIM inline geconfigureerd binnen het SSO-formulier. De waarden zijn hetzelfde; alleen de schermen verschillen.

Gerelateerde artikelen

• API Auth and RBAC in an AI Gateway — hoe identiteit doorwerkt in gateway-requests
• MCP Access Control: Securing AI Agents with an MCP Gateway — waar de door SCIM aangemaakte teams daadwerkelijk rechten op krijgen
• Enterprise MCP Access Control — directe versus overgeërfde rechten op organisatieschaal
• AI Governance Framework — waar provisioning past binnen het bredere beheersingskader
• MCP Security — het dreigingsmodel achter een strakke identiteitshygiëne

Conclusie

SCIM-provisioning wordt meestal verkocht op basis van het onboarding-verhaal, omdat onboarding zich goed laat demonstreren. De werkelijke winst zit echter aan de andere kant. De-provisioning is de foutmodus zonder feedbackloop — geen ticket, geen klacht, geen melding — en de enige duurzame oplossing is om het vertrek van een medewerker automatisch te laten doorstromen vanuit het ene systeem dat er al van op de hoogte is.

Op TrueFoundry vereist dat drie instellingen en één ontwerpbeslissing: schakel SCIM in, kopieer de base URL, genereer de token en bepaal eenmalig wat het team van elke groep mag doen. Daarna houdt het organigram je toegangsmodel automatisch bij, en accounts die niet meer zouden moeten bestaan, houden vanzelf op te bestaan — het enige offboarding-proces dat schaalbaar blijft bij een groeiend bedrijf.

Stel SCIM-provisioning in op TrueFoundry

Gratis beginnen