SSO en SCIM instellen voor een AI Gateway

De meeste AI-gateway beveiligingsincidenten zijn niet exotisch. Ze bestaan uit een API-sleutel van een vertrokken contractor die drie weken later nog steeds werkt, een gedeelde "team sleutel" die in een dozijn notebooks is geplakt en die niemand kan roteren zonder iedereen te verstoren, en een modeltoegangsbeleid dat alleen in het geheugen van één engineer zit. Enterprise AI-toegang faalt op saaie, vermijdbare manieren, en de oplossing is dezelfde identiteitsinfrastructuur die elk ander serieus enterprise-systeem al gebruikt: single sign-on voor authenticatie en SCIM voor lifecycle provisioning.

Dit artikel legt uit waarom AI-toegang via SSO en SCIM moet lopen in plaats van via statische sleutels, wat elk protocol doet, hoe ze samenkomen in de specifieke context van een AI gateway (console-inlog, modeltoegang, MCP-servertoegang, budgetten), en hoe u ze conceptueel instelt voor elke grote identity provider. Het is geschreven voor de platform- of security engineer die de taak heeft gekregen om "de AI gateway onder SSO te brengen" en het mechanisme moet begrijpen, in plaats van alleen door een wizard te klikken.

Wilt u SSO en SCIM gekoppeld hebben aan elk model en elke MCP-server die uw teams gebruiken? Boek een demo.

Waarom gedeelde sleutels falen en identiteit dit oplost

Begin bij wat de meeste teams daadwerkelijk doen: een langdurige API-sleutel, vaak één per team, soms één voor het hele bedrijf, die wordt doorgegeven om de gateway aan te roepen. Dit kent vier structurele problemen, en alle vier worden ze opgelost door op identiteit gebaseerde toegang.

• Geen toewijzing (attribution). Een gedeelde sleutel betekent dat elk verzoek er hetzelfde uitziet. U kunt niet zien wie de query heeft uitgevoerd die $400 aan tokens kostte, wat het doel van de observatie en budgettering per gebruiker tenietdoet die de gateway hoort te bieden.
• Geen levenscyclus. De sleutel weet niet en geeft er niet om dat iemand het bedrijf heeft verlaten. Het intrekken van de sleutel betekent dat deze moet worden geroteerd, wat betekent dat iedereen die deze legitiem gebruikt, moet worden bijgewerkt. In de praktijk wordt de sleutel dus nooit geroteerd en eindigt de toegang nooit.
• Geen granulariteit. Eén sleutel werkt of werkt niet. U kunt niet zeggen "dit team mag de goedkope modellen gebruiken maar niet het frontier model", omdat de sleutel geen identiteit bevat om op te filteren.
• Geen centrale controle. Toegangsbeleid bevindt zich overal waar de sleutels zich bevinden, wat neerkomt op overal en nergens.

SSO en SCIM vervangen dit door een model waarbij toegang een functie is van wie u bent in de identity provider en tot welke groepen u behoort. Authenticatie bewijst identiteit bij het inloggen. Provisioning houdt het beeld van de gateway van wie er bestaat, en wie tot welke groep behoort, automatisch synchroon met de IdP. Wanneer de IdP een account uitschakelt, stopt de toegang overal waar het account bereik had, zonder handmatige tussenkomst. Die enkele eigenschap, automatische deprovisioning, is de reden waarom dit niet optioneel is voor enterprise AI.

SSO en SCIM zijn niet hetzelfde

Ze worden regelmatig op één hoop gegooid, en dat is precies hoe achtergebleven toegang ontstaat. SSO logt mensen in. SCIM beheert of hun account en groepslidmaatschappen in de eerste plaats bestaan. SSO is een authenticatiegebeurtenis; SCIM is een levenscyclus-synchronisatie.

De valkuil is om SSO te configureren, te zien dat mensen inloggen met hun bedrijfsidentiteit, en het succesvol afgerond te verklaren. Alleen SSO betekent dat wanneer iemand wordt ge-offboard in de IdP, hun vermogen om in te loggen verdwenen is, maar als de gateway hun account en toegang buiten het systeem om heeft geprovisioneerd, of als ze nog een token of sleutel bezitten, het account en de bijbehorende rechten kunnen blijven bestaan. SCIM is wat ingrijpt in de gateway en het account en de groepslidmaatschappen verwijdert wanneer de IdP aangeeft dat de persoon weg is. U heeft beide nodig: SSO zodat inloggen gecentraliseerd is en door MFA wordt ondersteund, SCIM zodat het bestaan en de toegang de bron van de waarheid volgen.

Hoe dit zich vertaalt naar een AI gateway

Een AI gateway heeft specifieke elementen om te beschermen, en identiteit sluit op elk daarvan aan. De keten loopt van de identity provider naar een concreet beleid op modellen, MCP-servers en budgetten.

Doorloop de keten van links naar rechts:

1. SSO voor de console en voor API-toegang. Wanneer een engineer de console van de gateway opent, authenticeert deze via de IdP via SAML of OIDC in plaats van met een lokaal wachtwoord. De assertion of het ID-token bewijst de identiteit en bevat claims. Dezelfde identiteit ondersteunt programmatische toegang, zodat API-calls herleidbaar zijn tot een echt persoon of echte service, niet tot een anonieme gedeelde sleutel.
2. SCIM synchroniseert gebruikers en groepen. De IdP pusht gebruikersrecords en hun groepslidmaatschappen naar het SCIM-eindpunt van de gateway zodra ze veranderen. Een nieuwe medewerker die wordt toegevoegd aan de groep "ml-platform" in de IdP verschijnt in de gateway, in die groep, zonder dat iemand de gateway hoeft aan te raken.
3. Groepen worden gekoppeld aan RBAC-rollen. U definieert eenmalig dat de groep "ml-platform" koppelt aan één rol, en "finance-analysts" aan een andere rol. Deze koppeling vormt het hart van het ontwerp: dit is waar identiteit autorisatie wordt.
4. Rollen beheren de toegang tot modellen, MCP-servers en budgetten. Een rol bevat rechten: welke modellen deze mag aanroepen, welke MCP-servers deze mag bereiken, welke snelheidslimieten (rate limits) en tokenbudgetten van toepassing zijn. TrueFoundry dwingt budgetten en rate limits af per gebruiker, team en model, waarbij HTTP 429 wordt geretourneerd bij een overschrijding, zodat een rol zowel toegang kan verlenen als uitgaven kan maximeren.

Het resultaat is dat toegang tot uw duurste frontier model, of tot een gevoelige interne MCP-server, een eigenschap is van het IdP-groepslidmaatschap. Verleen het door iemand toe te voegen aan een groep in de IdP; trek het in door deze te verwijderen. De RBAC van de gateway wordt diepgaander behandeld in fijnmazige autorisatie, en het bredere kader over "hoe kies ik dit eigenlijk" bevindt zich in hoe kiest u een AI gateway.

Een concrete groep-naar-rol koppeling

Hier is een illustratieve koppeling om de abstractie concreet te maken. Pas de rolnamen en rechten aan op uw eigen beleid.

De laatste rij is waar het om draait. Verwijdering uit de IdP-groepen, wat SCIM automatisch doorvoert, brengt de rechten van een persoon terug tot nul. Geen ticket, geen handmatige sleutelrotatie, geen "zijn we vergeten hun toegang overal te verwijderen".

Bekijk hoe TrueFoundry IdP-groepen koppelt aan RBAC-rollen binnen de gateway. Boek een demo.

Stap voor stap instellen

De precieze schermen verschillen per identity provider, maar de conceptuele volgorde is hetzelfde voor Okta, Entra ID, Google Workspace, of elke SAML/OIDC- en SCIM 2.0 IdP. Verzin geen provider-specifieke labels uit het geheugen; volg de eigen documentatie van elke IdP voor de veldnamen. De structuur is als volgt:

Stap 1: Maak de applicatie aan in de IdP. Registreer de gateway in de identity provider als een enterprise applicatie. Dit is het object dat zowel de SSO-configuratie als later de SCIM-configuratie zal bevatten. Bepaal nu welke gebruikers en groepen aan deze applicatie worden toegewezen, aangezien alleen toegewezen gebruikers geprovisioneerd zullen worden.

Stap 2: Configureer SSO (metadata en claims). Kies SAML of OIDC. Wissel voor SAML metadata uit: de IdP levert zijn entity ID, sign-in URL en ondertekeningscertificaat; de gateway levert zijn assertion consumer service (ACS) URL en entity ID. Voor OIDC registreert u een client en wisselt u issuer URL, client ID en secret uit, en stelt u redirect URI's in. Configureer in beide gevallen de claims: minimaal het e-mailadres of de unieke id van de gebruiker, en cruciaal de groepslidmaatschappen van de gebruiker, omdat groepen zijn wat u aan rollen zult koppelen. Controleer of de groep-claim daadwerkelijk is opgenomen in de assertion of het token; een ontbrekende groep-claim is de meest voorkomende reden dat de rolkoppeling stilzwijgend faalt.

Stap 3: Schakel SCIM in (token en eindpunt). Zet provisioning aan. De gateway stelt een SCIM 2.0 basis-eindpunt (een URL) beschikbaar en u genereert een bearer token dat de IdP autoriseert om dit aan te roepen. Plak het eindpunt en het token in de provisioning-configuratie van de IdP. De IdP zal de verbinding testen door het SCIM-eindpunt aan te roepen; een succesvolle test betekent dat de IdP gebruikers en groepen in de gateway kan aanmaken, lezen, bijwerken en deactiveren.

Stap 4: Koppel attributen en groepen aan rollen. Configureer attribuutkoppelingen zodat de gebruikersvelden van de IdP (e-mail, weergavenaam, externe ID) het gebruikersrecord van de gateway vullen, en SCIM-groepspushes binnenkomen als gateway-groepen. Koppel vervolgens in de gateway elke groep aan een RBAC-rol met de bijbehorende model-, MCP-server- en budgetrechten, zoals in de tabel hierboven. Deze koppeling is het beleid; laat dit beoordelen door degene die verantwoordelijk is voor toegangsbeheer.

Stap 5: Test de volledige levenscyclus. Ga niet live op basis van alleen een inlogtest. Test alle drie de lifecycle-gebeurtenissen:

• Provisie: voeg een testgebruiker toe aan een gekoppelde groep in de IdP, bevestig dat deze in de gateway verschijnt in de juiste rol, en bevestig dat deze exact de modellen en servers kan aanroepen die die rol toestaat en niets anders.
• Wijziging: wijzig de groep van de testgebruiker in de IdP, bevestig dat hun gateway-rol en rechten dienovereenkomstig veranderen.
• Deprovisie: schakel de testgebruiker uit in de IdP, bevestig dat de SCIM-deactivering de toegang verwijdert, en bevestig dat een call die eerder werkte nu faalt. Dit is de stap die bewijst dat het probleem van achtergebleven toegang daadwerkelijk is opgelost.

De levenscyclus die SCIM automatiseert

De gehele waardepropositie zit in drie gebeurtenissen tijdens de looptijd van een werknemer of contractor, en SCIM verwerkt ze alle drie zonder dat een mens de gateway hoeft aan te raken.

• Instroom (Join). HR of IT voegt de persoon toe aan groepen in de IdP als onderdeel van de onboarding. SCIM provisioneert het gateway-account en verleent via groep-naar-rol koppeling precies de juiste rechten. De persoon heeft op dag één werkende, correct afgebakende AI-toegang zonder dat er aan de gateway-zijde een ticket nodig is.
• Doorstroom (Move). Iemand stapt over van product engineering naar het ML-platformteam. Hun IdP-groepslidmaatschap verandert. SCIM geeft de wijziging door; hun gateway-rol verandert; ze krijgen toegang tot de frontier modellen en verliezen toegang tot de dataservers van het oude team. Toegang volgt het organigram automatisch.
• Uitstroom (Leave). De persoon wordt ge-offboard. De IdP schakelt het account uit. SCIM deactiveert het gateway-account en verwijdert de groepslidmaatschappen. Elk recht, elk model, elke MCP-server, elk budget gaat onmiddellijk naar nul. Er is geen periode waarin een vertrokken persoon toegang behoudt, omdat er geen handmatige stap is om te vergeten.

Vergelijk dat met de situatie bij gedeelde sleutels: onboarding betekent het zoeken en delen van de juiste sleutel, doorstroom betekent dat er automatisch niets verandert, en uitstroom betekent dat iemand eraan moet denken om een sleutel te roteren die alle anderen verstoort wanneer deze wordt geroteerd, waardoor het niet gebeurt. De gap in de levenscyclus is precies waar beveiligingslekken ontstaan.

Voorbij mensen: agents en data residency

Menselijke identiteit via SSO en SCIM vormt het fundament, maar enterprise AI-toegang kent twee dimensies die mensen niet volledig afdekken.

Ten eerste: agents zijn ook aanroepers. Een autonome agent die modellen en MCP-servers aanroept, heeft een eigen identiteit, een eigen rol en een eigen budget nodig, niet een geleende menselijke sleutel. Hetzelfde RBAC-mechanisme dat menselijke groepen aan rollen koppelt, strekt zich uit tot agent-identiteiten, zodat een agent least-privilege toegang krijgt tot specifieke tools en een gemaximeerd budget. Dit is het natuurlijke vervolg op het identiteitswerk; zie AI agent identity en de MCP-specifieke controles in enterprise MCP governance.

Ten tweede: waar identiteit en data zich bevinden is van belang. Authenticatie en provisioning bepalen wie wat mag aanroepen; deployment bepaalt waar de verzoeken en hun data fysiek naartoe gaan. TrueFoundry kan worden geünstalleerd als SaaS, in-VPC, on-prem, of air-gapped, zodat het datavlak binnen uw netwerk blijft terwijl identiteit integreert met uw IdP. Voor gereguleerde workloads is deze scheiding het verschil tussen een bruikbare gateway en een compliance-blokkade; data residency en de scheiding tussen het control plane vs data plane behandelen hoe dat werkt.

Waar teams de fout in gaan

Ze configureren SSO en slaan SCIM over. Inloggen is gecentraliseerd, iedereen is tevreden, en offboarding laat nog steeds accounts en rechten achter omdat niets de deprovisioning synchroniseert. SSO zonder SCIM lost authenticatie op en negeert de levenscyclus. Configureer beide.

Ze testen deprovisioning nooit. Het provisiepad wordt getest omdat nieuwe gebruikers op dag één toegang nodig hebben. Het deprovisiepad, degene die u daadwerkelijk beschermt, wordt aangenomen. Schakel een testaccount uit en bevestig dat een eerder werkende call nu faalt, elke keer dat u de configuratie wijzigt.

Ze vergeten de groep-claim. SSO werkt, gebruikers loggen in, en vervolgens belandt iedereen in een standaard- of lege rol omdat de IdP-assertion geen groepslidmaatschappen bevatte. Rolkoppeling is volledig afhankelijk van de aanwezigheid en correcte benaming van de groep-claim. Verifieer dit in een daadwerkelijke assertion of token.

Ze houden een gedeelde sleutel aan als "back-up". Eén enkele actieve admin- of break-glass-sleutel doet het hele model teniet, omdat deze niet herleidbaar is en nooit wordt gedeprovisioneerd. Als u break-glass-toegang nodig heeft, maak er dan een op naam gesteld, geauditeerd en tijdelijk pad van, geen permanent gedeeld geheim.

Ze koppelen iedereen aan één brede rol. Provisioning via SCIM naar één enkele "alle gebruikers"-rol geeft u herleidbaarheid (attribution), maar geen least-privilege; iedereen kan het frontier model en elke MCP-server aanroepen. Het doel van groep-naar-rol koppeling is juist granulariteit. Modelleer echte teams en echte rechten.

Conclusie

Enterprise AI-toegang faalt niet op ingewikkelde manieren. Het faalt omdat een gedeelde sleutel langer meeging dan de persoon die hem gebruikte, omdat offboarding een handmatige stap was die iemand vergat, omdat niemand kon zeggen wie het tokenbudget had verbruikt. SSO en SCIM dichten die gaten door toegang een functie te maken van identiteit: SSO authenticeert elke inlog via uw identity provider, en SCIM houdt het beeld van de gateway over wie er bestaat, en wie tot welke groep behoort, automatisch synchroon met de bron van de waarheid.

Stel beide in, koppel groepen aan rollen met echte least-privilege rechten, en test het deprovisiepad totdat u er volledig op vertrouwt. Als u dat doet, wordt toegang tot uw duurste modellen en meest gevoelige MCP-servers iets dat u verleent door iemand aan een groep toe te voegen en intrekt door deze te verwijderen, onmiddellijk en overal. Datzelfde identiteitsfundament trekt u vervolgens door naar agent-identiteit, fijnmazige autorisatie per tool en de data-residency-controles die gereguleerde AI vereist.

Automatiseer instroom-, doorstroom- en uitstroomtoegang voor uw AI-stack. Boek een demo.