Enterprise
SCIM-provisioning vanuit je identity provider
Nieuwe medewerkers, functiewisselingen en vertrekkers stromen automatisch vanuit je IdP — geen handmatig accountbeheer, geen vergeten toegang die op een auditbevinding wacht.
SCIM-provisioning verbindt Ciao met je identity provider zodat gebruikersaccounts automatisch worden aangemaakt, bijgewerkt en gedeactiveerd naarmate je directory verandert. In tegenstelling tot handmatig accountbeheer verwijdert SCIM de menselijke stap waar offboarding faalt: wanneer een gebruiker in je IdP wordt gedeactiveerd, verspreidt de wijziging zich naar Ciao, en de omliggende admin-acties komen terecht in de append-only audit trail die je reviewers kunnen inspecteren.
Gepubliceerd 2026-07-03 · Laatst bijgewerkt 2026-07-03
Vergeten accounts zijn auditbevindingen in wording
Elke toegangsreview vindt ze: accounts van mensen die maanden geleden van functie zijn veranderd of vertrokken, nog steeds actief omdat deprovisioning afhing van een ticket dat nooit werd ingediend. In de meeste SaaS-tools is dat een blootstellingsprobleem. In een platform waar een ingelogde gebruiker wijzigingen aan productiesoftware kan prompten, is het ook een wijzigingsbeheerprobleem — een account van niemand, met de mogelijkheid om wijzigingen voor te stellen aan systemen waar je bedrijf op draait.
SCIM bestaat om de handmatige stap te verwijderen. Je identity provider is al de bron van waarheid voor wie hier werkt en tot welke groep ze behoren; SCIM maakt Ciao een abonnee van die waarheid in plaats van een aparte lijst die een beheerder moet onthouden te verzoenen.
Auditors zijn tot hetzelfde inzicht gekomen: toegangsreviews die afhankelijk zijn van handmatige verzoening verzamelen bevindingen, en levenscyclusautomatisering is de geaccepteerde oplossing. Als je organisatie SCIM al draait voor haar andere belangrijke systemen, is het uitbreiden ervan naar het platform dat software bouwt en deployt de consistente zet — en als Ciao je eerste SCIM-integratie zou zijn, zijn de uitroltapen hieronder bewust behoudend.
Wat SCIM-provisioning dekt
De dekking omvat de levenscyclusgebeurtenissen die je toegangsreviews daadwerkelijk testen:
- Accountaanmaak — Gebruikers die in je IdP aan Ciao worden toegewezen, krijgen automatisch accounts ingericht — geen aanvraagwachtrij, geen handmatige aanmaak.
- Attribuutupdates — Naam- en profielwijzigingen stromen vanuit de directory, zodat het accountrecord de persoon volgt zonder admin-tussenkomst.
- Mapping van groep naar rol — IdP-groepen kunnen worden gemapt naar Ciao-rollen, zodat rolgebaseerde toegangscontrole wordt aangestuurd door de directorystructuur die je team al bestuurt.
- Deactivering — Wanneer je IdP een gebruiker deactiveert, wordt hun Ciao-toegang verwijderd als onderdeel van de levenscyclusstroom — de stap die handmatige offboarding het vaakst mist.
- Een auditrecord — Provisioningwijzigingen zijn admin-acties, en admin-acties worden vastgelegd in de append-only audit trail naast prompts, merges en deploys.
Hoe een uitrol werkt
1. Begin bij SSO
SCIM gaat ervan uit dat SSO via SAML of OIDC al is ingericht, zodat authenticatie en provisioning één identiteitsbron delen.
2. Verbind de IdP
Configureer de SCIM-integratie in je identity provider tijdens onboarding, met het enterprise-team dat samenwerkt met je identiteitsengineers.
3. Map groepen naar rollen
Bepaal welke IdP-groepen overeenkomen met welke Ciao-rollen en projectscopes, en leg de mapping vast — het wordt onderdeel van je toegangscontroledocumentatie.
4. Pilot met één groep
Wijs een kleine groep toe, en verifieer dat aanmaak-, update- en deactiveringsgebeurtenissen aankomen zoals verwacht voordat je uitbreidt. Neem minstens één deactivering op in de pilot — het is de gebeurtenis die het meest telt en die teams het vaakst vergeten te testen.
5. Verifieer in de audit trail
Bevestig dat provisioninggebeurtenissen verschijnen als admin-acties in de append-only trail, zodat je toegangsreviews bewijs hebben in plaats van aannames.
SCIM, SSO, RBAC en de audit trail als één systeem
Deze vier controls zijn ontworpen om samen te worden beoordeeld. SSO beantwoordt hoe mensen authenticeren; SCIM beantwoordt hoe accounts ontstaan en ophouden te bestaan; rolgebaseerde toegangscontrole beantwoordt wat een geauthenticeerde persoon mag doen; en de append-only audit trail legt vast wat ze daadwerkelijk deden — prompts, merges, deploys en admin-acties. Een reviewer kan één persoon traceren van directorygroep naar Ciao-rol naar een specifieke vastgelegde actie, wat het traceerbaarheidsverhaal is dat de meeste toegangscontroleframeworks eigenlijk vragen.
In de praktijk verandert de combinatie de textuur van een toegangsreview. In plaats van beheerders te interviewen over wat ze denken dat er is gebeurd, leest de reviewer wat er is gebeurd: de directorygebeurtenis, de resulterende rol, de acties eronder ondernomen. De reviewtijd verschuift van bewijsverzameling naar oordeelsvorming, waar het thuishoort.
Levenscyclusgebeurtenissen en hun effect
Gebruik dit als checklist voor je pilot: draai elke gebeurtenis met een testgebruiker en verifieer het effect.
| Levenscyclusgebeurtenis | Wat er in Ciao gebeurt | Waar je het verifieert |
|---|---|---|
| Gebruiker toegewezen in IdP | Account ingericht met gemapte rol | Admin-acties in de audit trail |
| Attributen veranderen | Accountrecord bijgewerkt vanuit de directory | Accountdetail en audit trail |
| Groepslidmaatschap verandert | Gemapte rol en scope volgen de directory | RBAC-configuratie en audit trail |
| Gebruiker gedeactiveerd in IdP | Ciao-toegang verwijderd via de levenscyclusstroom | Audit trail en toegangsreview |
| Workspace-inhoud | Apps en code blijven eigendom van de workspace | Code-export op elk moment beschikbaar |
Verificatienotities
Provisioning is een control die je team moet testen, niet aannemen. Draai tijdens de evaluatie de levenscyclus end-to-end met een testgebruiker — toewijzen, bijwerken, deactiveren — en bekijk de resultaten in de audit trail. Integratiespecifieke details voor jouw IdP worden tijdens onboarding behandeld, en het security pack, op aanvraag beschikbaar via de contactpagina, documenteert de identiteitsarchitectuur voor reviewers die het detail schriftelijk nodig hebben.
Als je uitrol ongebruikelijke beperkingen heeft — gedeelde accounts om te elimineren, contractanten op een aparte IdP, gefaseerde migraties — zet ze dan schriftelijk bij het enterprise-team voordat de pilot start, zodat de configuratie wordt ontworpen op basis van jouw realiteit in plaats van er achteraf op aangepast te worden.
Veelgestelde vragen
Welke identity providers kunnen SCIM-provisioning aansturen?
SCIM is een standaard, en de identity providers die enterprises doorgaans draaien — Okta, Microsoft Entra ID en vergelijkbare — implementeren het. Bevestig je specifieke IdP en configuratie met het enterprise-team tijdens onboarding.
Wat gebeurt er met iemands werk wanneer ze worden gedeprovisioneerd?
Hun toegang wordt verwijderd; het werk verdwijnt niet. Applicaties en code behoren toe aan de workspace, met 100% code-eigendom en export naar je eigen repo op elk moment beschikbaar — het offboarden van een persoon strandt de software nooit.
Vervangt SCIM just-in-time provisioning?
Ze lossen verschillende helften op. JIT maakt een account aan bij eerste aanmelding; SCIM beheert de doorlopende levenscyclus inclusief updates en deactivering. Veel uitrollen gebruiken JIT tijdens de pilot en SCIM voor de volledige uitrol.
Worden provisioning- en deprovisioningacties gelogd?
Ja. Het zijn admin-acties, vastgelegd in de append-only audit trail naast prompts, merges en deploys — zodat toegangsreviews vastgelegde gebeurtenissen kunnen citeren in plaats van screenshots.
Hoe valideren we SCIM voordat we het bedrijfsbreed uitrollen?
Pilot met een testgroep: toewijzen, attributen wijzigen, groepen verplaatsen, deactiveren, en verifieer elke gebeurtenis in de audit trail. Het enterprise-team ondersteunt de pilot, en het security pack documenteert de identiteitsarchitectuur onder review.