SSO voor interne apps: koppel SAML/OIDC-claims aan rollen en teams

Waarom claim mapping belangrijk is voor interne apps

Single sign-on klinkt simpel: klik "Sign in with Okta" of "Sign in with Azure AD" en je bent binnen. Het lastige is wat er daarna gebeurt. Zonder duidelijke claim mapping krijgen mensen vaak te veel toegang (een supportagent ziet salarisgegevens) of te weinig toegang (een nieuwe medewerker kan op dag één niet bij de benodigde tool).

Interne apps zijn lastiger dan publieke apps omdat ze door meerdere teams worden gedeeld en constant veranderen. Eén tool kan tegelijk door Support, Finance en Sales worden gebruikt. Organisatiestructuren schuiven, contractors komen en gaan, en teams worden hernoemd of opgesplitst. Als toegangsregels alleen in iemands hoofd leven, zal SSO die rommel trouw in je app kopiëren.

Claim mapping is hoe je identity-data van je identity provider (IdP), zoals groepen, afdeling of functietitel, omzet naar permissies die je app begrijpt. Dat betekent meestal beslissen:

• Welke rollen er in de app bestaan (admin, manager, viewer, etc.)
• Tot welke teams of workspaces gebruikers behoren
• Wat elke rol kan doen en wat elk team kan zien
• Wie automatisch toegang krijgt en wie goedkeuring nodig heeft

Twee risico's veroorzaken de meeste problemen:

• Verkeerde mappings. Een groepsnaam komt overeen met de verkeerde rol, of een brede "All Employees"-groep geeft per ongeluk admin-rechten.
• Ontbrekende claims. De IdP stuurt voor sommige gebruikers geen groepen, een attribuut is leeg, of het token is te groot en wordt ingekort.

Je app heeft veilige standaardinstellingen nodig zodat ontbrekende of onverwachte data nooit in per ongeluk toegang verandert.

SAML vs OIDC-claims in gewone taal

Als je inlogt met SSO, stuurt je IdP een klein pakket feiten over je naar de app. Elk feit is een claim, in feite een gelabeld veld zoals "email = [email protected]" of "department = Finance".

SAML en OIDC kunnen vergelijkbare feiten transporteren, maar ze verpakken ze anders.

SAML is gebruikelijk in oudere enterprise-omgevingen. Het stuurt meestal een XML-document (een assertion) met attributen. Die attributen zijn de claims die je app leest.

OIDC is nieuwer en gebouwd op OAuth 2.0. Het stuurt meestal een ondertekend JSON-token (een ID-token) plus optionele user info, waarbij de velden in het token de claims zijn.

Voor interne apps gaat het meestal om een kleine set claims:

• E-mailadres
• Een stabiel gebruikers-ID van de IdP (subject)
• Volledige naam (of voor- en achternaam)
• Groepslidmaatschappen (teams, security groups)
• Afdeling of functietitel

Één onderscheid voorkomt veel verwarring:

Authenticatie beantwoordt de vraag "wie is deze gebruiker?" Claims zoals een stabiel gebruikers-ID en e-mail helpen je de SSO-login aan het juiste account te koppelen.

Autorisatie beantwoordt de vraag "wat mag deze persoon doen?" Claims zoals groepen of afdeling helpen je de gebruiker aan rollen en teams binnen de app te koppelen.

Twee mensen kunnen succesvol authenticeren, maar alleen degene met een "Finance"-groepclaim mag bij een factureringsscherm.

Rollen en teams: bepaal waar je naartoe mapt

Voordat je SAML-attributen mappt of OIDC-claims omzet naar permissies, wees duidelijk over twee verschillende dingen die je app moet weten:

• Rollen definiëren wat iemand kan doen (permissies).
• Teams definiëren waar iemand hoort (scope).

Rollen beantwoorden vragen als: kan deze persoon bekijken, bewerken, goedkeuren, exporteren, gebruikers beheren of instellingen wijzigen?

Teams beantwoorden vragen als: bij welke afdeling, regio, wachtrij of kostenplaats hoort deze persoon, en welke records zouden ze moeten zien?

Houd rollen klein en stabiel. De meeste interne apps hebben maar een paar rollen nodig die zelden veranderen, zelfs als mensen van plek wisselen. Teams moeten de dagelijkse realiteit weerspiegelen: Support Tier 2, EMEA-dekking, een tijdelijke wachtrij-eigenaar.

Least privilege is het veiligste standaardgedrag. Veel interne apps redden het met drie rollen:

• Viewer: kan data lezen en zoeken uitvoeren
• Editor: kan records aanmaken en bijwerken
• Admin: kan instellingen, gebruikers en toegangsregels beheren

Schrijf in gewone taal op wat elke rol toestaat. Dat voorkomt "surprise admin"-toegang als een groepsnaam verandert en maakt latere reviews veel makkelijker.

Groepsgebaseerde toegang: hoe je over IdP-groepen denkt

Groepsgebaseerde toegang betekent dat je app geen beslissing per persoon neemt. In plaats daarvan onderhoudt de IdP groepslidmaatschap en map je app die groepen naar rollen en teams.

Begin met beslissen wat een groep verleent. In veel tools map je één groep naar één rol (zoals "Support Agent") en optioneel één team (zoals "Tier 2"). Het sleutelprincipe is dat de mapping saai en voorspelbaar blijft: dezelfde groep betekent altijd dezelfde toegang.

Wanneer gebruikers in meerdere groepen zitten

Mensen behoren vaak tot meer dan één IdP-groep. Je hebt een regel nodig om dat op te lossen, en je moet die stabiel houden.

Veelvoorkomende benaderingen:

• Additieve regels: combineer permissies van alle overeenkomende groepen (werkt als permissies nauw beperkt zijn)
• Prioriteitsregels: kies de groep met de hoogste prioriteit en negeer de rest (handig bij conflicterende rollen)
• Hybride: additief voor teams, prioriteit voor rollen

Wat je ook kiest, documenteer het. Het later veranderen kan ertoe leiden dat gebruikers plotseling meer of minder toegang krijgen.

Gebruik een naamgevingsconventie die schaalbaar is

Duidelijke groepsnamen verminderen fouten en maken audits makkelijker. Een praktisch patroon is:

• --

Bijvoorbeeld support-tool-prod-agent of finance-tool-staging-viewer. Dit helpt voorkomen dat vage namen zoals "Admins" hergebruikt worden voor meerdere apps.

Als een gebruiker tot geen relevante groep behoort, begin dan bij geen toegang (of een duidelijk beperkte gasttoestand) en toon een bericht dat uitlegt hoe toegang aangevraagd kan worden.

Accountkoppeling: SSO-gebruikers aan app-accounts matchen

SSO bewijst wie iemand is, maar je app moet nog steeds beslissen aan welk bestaand account die identiteit gekoppeld wordt. Zonder accountkoppeling kan dezelfde persoon in de loop der tijd meerdere accounts krijgen omdat identifiers veranderen: nieuw e-mailadres, naamsupdates, verhuizen tussen dochterbedrijven, of wisselen van IdP.

Kies één stabiele, unieke sleutel als primaire match.

• Voor OIDC is dat meestal de IdP's sub-claim (subject).
• Voor SAML is dat vaak een persistente NameID of een speciaal onveranderlijk gebruikersattribuut.

Sla die waarde op als de "IdP user ID" samen met de IdP issuer/entity ID, zodat dezelfde sub van een andere IdP niet kan botsen.

E-mail is handig, maar behandel het als convenience key, niet als bron van waarheid. Mensen veranderen e-mails door naamswijzigingen, domeinmigraties of fusies. Aliassen en gedeelde inboxen kunnen ook verrassende matches veroorzaken. Als je op e-mail matcht, doe dat alleen als het IdP-signaal geverifieerd is en overweeg een eenmalige bevestiging.

Bij de eerste login kiezen de meeste interne tools één onboardingpatroon:

• Auto-create: maak direct een account aan en wijs minimale toegang toe.
• Invite-only: laat alleen logins toe voor gebruikers die vooraf in je app zijn aangemaakt of goedgekeurd.
• Approval flow: maak het account aan, maar blokkeer toegang totdat een manager of admin rol/team toewijst.

Een veilige standaard is auto-create met geen permissies, en daarna toegang toekennen op basis van groepen of een goedkeuringsstap.

Stapsgewijs: map claims naar rollen en teams

Goede claim mapping laat SSO onzichtbaar voelen: mensen loggen in en komen op de juiste plek met de juiste toegang.

Begin met het uitschrijven van je toegangsmodel in gewone taal. Noem elke rol (Viewer, Agent, Manager, Admin) en elk team (Support, Finance, IT), plus wie ze moeten krijgen en waarom.

Controleer daarna wat je IdP daadwerkelijk kan sturen. Voor SAML of OIDC wil je doorgaans een stabiel gebruikers-ID (subject of NameID), e-mail en één of meer groepattributen. Leg exacte groepswaarden vast zoals ze verschijnen, inclusief hoofdletters en prefixes. "Support" en "support" zijn niet hetzelfde.

Een praktisch stappenplan:

• Definieer rollen en teams, en wijs een eigenaar toe aan elk (iemand die wijzigingen kan goedkeuren).
• Maak een lijst van beschikbare claims en exacte groepsnamen van de IdP, inclusief randgevallen (contractors, gedeelde inboxen).
• Schrijf mappingregels: group-to-role, group-to-team en een override-volgorde wanneer meerdere groepen matchen.
• Test met 3 tot 5 echte gebruikersrollen (nieuwe medewerker, manager, contractor, admin) met echte IdP-accounts.
• Schrijf voor elke testgebruiker eerst het verwachte rol/team-resultaat, log in en vergelijk.

Houd één klein voorbeeld bij de hand om regels concreet te maken. Als een gebruiker in "okta-support" zit, wordt die Support-team plus Agent-rol. Als die ook in "okta-support-managers" zit, overschrijft de Manager-rol de Agent.

Voeg ten slotte een eenvoudige manier toe om te debuggen. Log de ruwe ontvangen claims (veilig), de regels die matchten en het uiteindelijke rol/team-resultaat. Wanneer iemand zegt: "Ik heb ingelogd, maar ik zie mijn tool niet", verandert dit een gokspel in een snelle check.

Veilige standaardinstellingen wanneer claims ontbreken

Ontbrekende claims zijn normaal. De IdP stuurt misschien geen groepen voor service-accounts, een connector kan een veld weglaten, of een gebruiker zit midden in een migratie. Behandel "geen data" als "geen vertrouwen."

De veiligste standaard is deny-by-default: geen rol, geen team, geen toegang. Als je toch toegang moet toestaan zodat iemand toegang kan aanvragen, maak die dan alleen-lezen en duidelijk beperkt.

Kies één gedrag en documenteer het:

• Blokkeer login met een duidelijk bericht: "Je account heeft geen toegewezen toegang. Neem contact op met support."
• Sta beperkte toegang toe met een waarschuwing en schakel gevoelige acties uit.
• Maak het gebruikersrecord aan maar wijs geen rol of team toe totdat goedkeuring is gegeven.

Geef nooit tijdelijk admin-rechten.

Plan voor gedeeltelijke data. Als je een e-mail krijgt maar geen groepen, kun je nog steeds een account aanmaken en het naar goedkeuring routen. Als je groepen krijgt maar geen stabiele identifier, vermijd dan automatisch koppelen aan een bestaand account omdat dat de verkeerde persoon kan koppelen.

Heb een escalatiepad voor mislukte matches:

• Een benoemde eigenaar (IT of app-admin) die toegang kan goedkeuren
• Een handmatige roltoewijzing met een auditnotitie
• Een manier om claims opnieuw te controleren bij de volgende login
• Een time-out voor "pending access"-accounts

Wijzigingen, verwijderingen en offboarding afhandelen

Mensen wisselen van team, krijgen een andere manager of verlaten het bedrijf. Behandel dit als normaal in je SSO-setup.

Als iemand van team verandert, werk dan de toegang bij bij de volgende login: evalueer groepsclaims opnieuw en pas de huidige mapping toe. Vermijd "plakkerige" toegang die voor altijd blijft omdat het ooit was toegekend.

Vertrekkers zijn anders. Wachten op de volgende login is niet voldoende. Je wilt dat hun toegang snel stopt, ook als ze nog een actieve sessie hebben. Dat betekent meestal dat het account in de IdP wordt uitgeschakeld en je app een uitgeschakeld of ontbrekend identity direct als geblokkeerd behandelt.

Deprovisioning moet voorspelbaar zijn: disable de gebruiker, verwijder teamlidmaatschappen en bewaar auditdata. Je moet vaak records zoals goedkeuringen, opmerkingen en geschiedenis bewaren voor compliance, terwijl je nieuwe acties blokkeert.

Contractors en tijdelijke toegang verdienen extra zorg. Plaats ze in tijdgebonden groepen in de IdP of koppel een reviewdatum aan hun rol zodat toegang niet blijft hangen na het project.

Een praktisch offboardingbeleid:

• Hercontroleer claims bij elke login en vernieuw teamlidmaatschap vanuit de IdP
• Wanneer een gebruiker uit de vereiste groepen wordt verwijderd, verlaag privileges meteen (volgende login of volgende sync)
• Schakel het account uit en bewaak auditsporen en eigendomsgeschiedenis
• Vereis een einddatum voor contractor-toegang en review voor verlenging
• Voer periodieke toegangsreviews uit voor gevoelige rollen zoals finance of admin

Veelgemaakte fouten en valkuilen om te vermijden

De meeste SSO-uitval wordt niet veroorzaakt doordat SAML of OIDC "moeilijk" is. Het gebeurt omdat de app onveilige aannames maakt over mensen, groepen en identifiers.

Een veelgemaakte fout is het mengen van role mapping met team mapping. Rollen zijn "wat mag je doen?" Teams zijn "waar hoor je bij?" Als je een teamgroep rechtstreeks naar een krachtige rol zoals Admin mapt, geef je vaak brede toegang aan iedereen die toevallig in dat team zit.

Een andere valkuil is vertrouwen op e-mail als enige identifier voor accountkoppeling. E-mails veranderen en aliassen kunnen duplicaten creëren. Geef de voorkeur aan een stabiele IdP user ID (zoals subject/NameID) als primaire sleutel en behandel e-mail als weergave- en notificatieveld.

Andere veelvoorkomende problemen:

• Open fail wanneer groepen ontbreken (standaard naar geen of lage toegang, niet volledige toegang)
• Onduidelijke groepsnamen die hergebruikt worden over dev, staging en productie
• Groepslidmaatschap behandelen als een permissielijst zonder te beoordelen wat elke groep daadwerkelijk betekent
• Niet omgaan met multi-team gebruikers die toegang tot meer dan één gebied nodig hebben zonder admin te worden
• Partners en contractors vergeten die geïsoleerd moeten worden van medewerkers-only teams

Test randgevallen vóór livegang. Een finance-analist bij incident response kan twee teams en één verhoogde rol nodig hebben. Als je regels slechts één team toelaten, verliest die persoon toegang of krijgt te veel permissies.

Snelle checklist voordat je live gaat

Voer een dry run uit met een paar testaccounts uit elk team voordat je SSO voor iedereen inschakelt. De meeste toegangproblemen verschijnen onmiddellijk wanneer je een nieuwe medewerker, een rolwijziging en een offboarding-case test.

Begin met accountkoppeling. Kies één unieke identifier die niet verandert, en houd je eraan. In OIDC is dit meestal sub. In SAML is het vaak NameID of een specifiek onveranderlijk attribuut.

Bepaal vervolgens wat er gebeurt als claims ontbreken. De veiligste standaard is geen verhoogde toegang (en in veel apps geen toegang) wanneer groep- of rolclaims ontbreken of leeg zijn. Zorg dat je minstens één laag-privilege rol hebt die mensen toelaat zonder gevoelige acties bloot te geven, als dat bij je workflow past.

Een eenvoudige pre-launch checklist:

• Bevestig dat je linking-identifier stabiel en uniek is (en dat je het in logs kunt zien)
• Controleer dat ontbrekende groepsclaims geen hogere toegang geven dan een laag-privilege rol
• Vereis dat admin-toegang overeenkomt met een expliciete admin-groep, plus een tweede goedkeuringsstap (ook handmatig)
• Test verwijdering: wanneer een gebruiker een groep verlaat, daalt toegang bij de volgende login (of sync)
• Schrijf mappingregels zodat een collega ze op één pagina kan begrijpen

Voorbeeld: een support- en finance-intern tool met SSO-groepen

Stel je een operationele tool voor die dagelijks door Support, Finance en een paar managers wordt gebruikt. Je wilt dat mensen inloggen en direct de juiste schermen en acties krijgen zonder dat een admin accounts handmatig moet herstellen.

Maak een paar IdP-groepen en map ze naar in-app-rollen en teams:

• ops-support -> Rol: Support Agent, Team: Support
• ops-finance -> Rol: Finance Analyst, Team: Finance
• ops-managers -> Rol: Manager, Team: Management

Zo ziet het eruit in de praktijk.

Nu een case met e-mailwijziging: Omar verandert van [email protected] naar [email protected]. Omdat de app accounts linkt op basis van het stabiele IdP user ID (zoals sub voor OIDC, of een persistente NameID voor SAML) in plaats van e-mail, krijgt hij geen duplicaataccount. Hij behoudt dezelfde geschiedenis en audittrail.

Om toegang zonder giswerk te verifiëren, houd een "effective access"-weergave bij die de gelinkte IdP-identity van de gebruiker, ontvangen groepen, resulterende rol en team toont. Als iets niet klopt, zie je snel of het een IdP-probleem, een mappingregel-probleem of een ontbrekende claim is.

Volgende stappen: houd toegang voorspelbaar na organisatieveranderingen

Het moeilijkste deel is niet de eerste lancering. Het is het behouden van overzicht na reorganisaties, nieuwe teams en "tijdelijke" uitzonderingen.

Houd een eendelige mappingdoc bij die antwoord geeft op:

• Welke IdP-groepen naar welke app-rollen en teams mappen
• Wat de default is wanneer een claim ontbreekt (en wie wijzigingen goedkeurt)
• Wie eigenaar is van elk risicovolle rol (finance admin, user admin, data export)
• Hoe contractors en service-accounts worden behandeld
• Waar de bron van waarheid ligt (IdP vs app)

Voer een kleine pilot uit met één afdeling met duidelijke grenzen, los randgevallen op en breid uit zonder nieuwe regels uit te vinden. Stel een terugkerende review in voor toegang die echte schade kan veroorzaken: maandelijks voor admin en risicovolle rollen, per kwartaal voor normale rollen.

Als je de interne app zelf bouwt, helpt het wanneer rollen, teams en businesslogica dicht bij elkaar blijven zodat wijzigingen makkelijk te testen zijn. AppMaster (appmaster.io) is één optie voor teams die rollen en workflows visueel willen modelleren en echte backend-, web- en mobiele code willen regenereren als vereisten veranderen, zonder stapels eenmalige permissie-fixes.