Je identity provider is het vertrouwensanker voor elke toegangsbeslissing in een Zero Trust model. Als het correct is geconfigureerd, bepaalt het wie welke applicatie bereikt, vanaf welk apparaat, onder welke omstandigheden. Als het verkeerd geconfigureerd is, wordt het het enige punt van mislukking dat je hele beveiligingsbeleid ondermijnt.
Deze gids beschrijft hoe identity providers werken, hoe SSO protocollen zoals SAML en OIDC in het plaatje passen en hoe je je IdP kunt verbinden met een Zero Trust Network Access laag. De gids is geschreven voor IT-managers van Europese organisaties in het middensegment die praktische integratiestappen nodig hebben, geen theorie.
Hoe je identity provider verbinden met Zero Trust toegang
- Kies een IdP die SAML 2.0 en OIDC ondersteunt, zoals Microsoft Entra ID, Okta of Google Workspace.
- Wissel metadata uit tussen uw IdP en uw ZTNA-platform om de vertrouwensrelatie tot stand te brengen.
- Breng gebruikersgroepen en rollen uit uw directory in kaart in het toegangsbeleid op applicatieniveau.
- Schakel apparaatposture checks in zodat toegangsbeslissingen identiteit en apparaatgezondheid combineren.
- Activeer SCIM provisioning om gebruikersaccounts automatisch te synchroniseren.
- Test met een pilotgroep en dwing daarna het beleid met de laagste rechten af voor alle applicaties.
Wat is een identity provider en waarom is het belangrijk voor toegangscontrole?
Een identity provider (IdP) is het systeem dat gebruikers authenticeert en vertrouwde tokens afgeeft aan de applicaties die ze moeten bereiken. Het is de enige bron van waarheid over wie iemand is, tot welke groepen hij behoort en of zijn aanmelding voldoet aan uw beveiligingsvereisten.
Praktisch gezien regelt je IdP drie dingen. Het verifieert referenties (wachtwoorden, MFA, biometrie). Het onderhoudt gebruikersattributen zoals rollen, groepslidmaatschappen en e-mailadressen. En het geeft cryptografisch ondertekende tokens uit die downstream applicaties vertrouwen zonder hun eigen authenticatie uit te voeren.
Voor IT-teams die 50 tot 400 gebruikers in hybride omgevingen beheren, is de IdP het enige onderdeel dat elke toegangsstroom raakt. Externe medewerkers die zich authenticeren voor interne apps, aannemers die tijdelijke toegang aanvragen, serviceaccounts die API’s aanroepen: dit gaat allemaal eerst langs uw identity provider.
Veelgebruikte identiteitsproviders in Europese middenmarktomgevingen zijn Microsoft Entra ID (voorheen Azure AD), Okta, Google Workspace en Ping Identity. Elk ondersteunt de federatieprotocollen waar Zero Trust toegangslagen van afhankelijk zijn.
Het verschil tussen een IdP en een serviceprovider
Het onderscheid is belangrijk wanneer je integraties configureert. Je IdP verifieert identiteit en geeft tokens uit. Een service provider (SP) gebruikt deze tokens en verleent toegang tot een specifieke resource. Je ERP-systeem, je SASE-platform, je projectmanagementtool: dit zijn allemaal serviceproviders die vertrouwen op asserties van je IdP.
| Identiteitsprovider (IdP) | Dienstverlener (SP) | |
|---|---|---|
| Primaire rol | Authenticeert gebruikers, geeft tokens uit | Verleent toegang op basis van vertrouwde tokens |
| Eigendom van gegevens | Gebruikersdirectory, referenties, groepslidmaatschappen | Toepassingsbronnen en -gegevens |
| Focus op beleid | Authenticatiebeleid (MFA, voorwaardelijke toegang) | Autorisatiebeleid (rollen, machtigingen) |
| Voorbeelden | Microsoft Entra ID, Okta, Google Workspace | Salesforce, Jimber SASE, ServiceNow |
Hoe SSO je IdP verbindt met elke applicatie
Single sign-on (SSO) stelt een gebruiker in staat om zich één keer te authenticeren bij de IdP en vervolgens toegang te krijgen tot meerdere applicaties zonder de referenties opnieuw in te voeren. Dit is niet alleen een gemaksfunctie. Het vermindert wachtwoordmoeheid, vermindert het risico op hergebruik van inloggegevens tussen verschillende services en geeft IT één plek om het authenticatiebeleid af te dwingen.
Wanneer een gebruiker een beschermde applicatie opent, stuurt de SP hem door naar de IdP. De IdP verifieert de gebruiker (controle van MFA, device posture, conditionele toegangsregels) en geeft vervolgens een token terug aan de SP. De SP valideert het token en verleent toegang. Als de gebruiker naar een tweede applicatie gaat, herkent de IdP de bestaande sessie en geeft een nieuw token af zonder opnieuw om referenties te vragen.
Voor IT-managers is het operationele voordeel aanzienlijk. Eén plek om MFA af te dwingen. Eén plek om een gecompromitteerde account uit te schakelen. Eén plek om authenticatielogs te bekijken. Met SSO op zijn plaats betekent het ontslag van een vertrekkende medewerker het uitschakelen van één IdP-account in plaats van het doorzoeken van tientallen individuele applicatie-aanmeldingen.
SAML vs OIDC: welk protocol past bij jouw omgeving
Twee protocollen domineren identiteitsfederatie in bedrijfsomgevingen. De keuze hangt af van je applicatielandschap en integratievereisten.
SAML 2.0
Security Assertion Markup Language (SAML) is een op XML gebaseerde standaard die is ontworpen voor webbrowser SSO. Het wordt breed ondersteund door bedrijfsapplicaties en blijft de standaardkeuze voor on-premises en legacy webapps. Een typische SAML flow werkt als volgt: de gebruiker vraagt een beschermde bron aan, de SP genereert een authenticatieverzoek en stuurt de browser door naar de IdP, de IdP authenticeert de gebruiker en stuurt een digitaal ondertekende XML assertie terug, de SP valideert de handtekening en verleent toegang.
SAML is volwassen en wordt breed ondersteund, maar het is veelomvattend. De XML payloads zijn groot en mobiele en single-page applicaties gaan er vaak onhandig mee om.
OpenID Connect (OIDC)
OIDC is een moderne authenticatielaag die bovenop OAuth 2.0 is gebouwd. Het gebruikt lichtgewicht JSON Web Tokens (JWT) in plaats van XML-bevestigingen. OIDC is beter geschikt voor cloud-native toepassingen, mobiele apps en API’s. Het ondersteunt dezelfde identiteitsfederatie als SAML, maar met minder overhead en betere tooling voor ontwikkelaars.
Wanneer gebruiken?
| Criterium | SAML 2.0 | OpenID Connect (OIDC) |
|---|---|---|
| Past het best | Bedrijfswebapps, legacysystemen | Cloud-native apps, mobiel, API’s |
| Token-indeling | XML bevestiging | JSON-webadoken (JWT) |
| Complexiteit | Hoger (XML parsing, certificaatbeheer) | Lager (JSON, standaard HTTP-stromen) |
| Mobiele ondersteuning | Beperkt | Eigen |
| Adoptietrend | Stabiel, wijdverspreid | Groeiend, voorkeur voor nieuwe integraties |
De meeste omgevingen in het middensegment gebruiken beide. Uw legacy ERP-systeem gebruikt waarschijnlijk SAML. Uw cloud-native SaaS tools ondersteunen waarschijnlijk OIDC. Een capabele IdP ondersteunt beide protocollen vanuit dezelfde directory, dus u hoeft niet voor één van beide te kiezen.
Hoe SCIM uw directory en applicaties synchroon houdt
Door SSO te configureren worden gebruikers geauthenticeerd. Maar hoe zit het met provisioning? Wanneer een nieuwe medewerker in dienst treedt, moet zijn account verschijnen in downstream applicaties. Wanneer iemand vertrekt, moet zijn toegang weer verdwijnen. Dit handmatig beheren in een dozijn applicaties zorgt voor vertragingen en gaten in de beveiliging.
System for Cross-domain Identity Management (SCIM) lost dit op. SCIM is een standaardprotocol dat automatisch gebruikersaccounts, groepslidmaatschappen en attributen synchroniseert tussen je IdP en aangesloten applicaties. Wanneer HR een gebruiker aanmaakt in de directory, pusht SCIM die account naar elke geïntegreerde applicatie. Wanneer het account wordt uitgeschakeld, verwijdert SCIM overal de toegang.
Voor NIS2-naleving is dit van belang. De richtlijn verwacht van organisaties dat ze aantonen dat de toegang gepast is en onmiddellijk wordt ingetrokken wanneer deze niet langer nodig is. Handmatige provisioning met spreadsheets en tickets voldoet daar niet aan. SCIM-gebaseerde automatisering biedt het controlespoor dat toezichthouders verwachten.
Waarom je identity provider het vertrouwensanker is voor Zero Trust
Zero Trust draait het traditionele beveiligingsmodel om. In plaats van iedereen binnen de netwerkperimeter te vertrouwen, moet elk verzoek om toegang worden geverifieerd. Je IdP is de basis van die verificatie.
In een Zero Trust Network Access architectuur onderschept de ZTNA laag elke verbindingspoging. Voordat toegang wordt verleend tot een specifieke applicatie, wordt de identiteit van de gebruiker gecontroleerd (geleverd door uw IdP via SAML of OIDC), de beveiligingsstatus van het apparaat (OS-versie, schijfversleuteling, status van eindpuntbeveiliging) en het toegangsbeleid voor die specifieke applicatie en rol.
Dit is fundamenteel anders dan toegang via VPN. Een VPN authenticeert één keer en verleent dan brede netwerktoegang. ZTNA authenticeert per applicatie en evalueert continu opnieuw. De IdP maakt dit mogelijk door een rijke identiteitscontext te bieden, niet alleen een gebruikersnaam, maar ook groepslidmaatschappen, authenticatiesterkte en sessiemetadata die de ZTNA-laag gebruikt voor elke toegangsbeslissing.
Hoe IdP-gedreven ZTNA er in de praktijk uitziet
Stel je voor dat een financieel teamlid thuis werkt. Ze openen hun browser en navigeren naar de factureringsapplicatie. De ZTNA laag verwijst door naar de IdP voor authenticatie. De IdP controleert hun geloofsbrieven, verifieert MFA en evalueert voorwaardelijke toegangsregels (is dit een beheerd apparaat? is schijfversleuteling ingeschakeld?). Als alles voldoet, geeft de IdP een token uit met de groepslidmaatschappen van de gebruiker. De ZTNA-laag leest die groepen, bevestigt dat de gebruiker geautoriseerd is voor de facturatie-app en verleent toegang tot die specifieke applicatie. Niets anders op het netwerk is zichtbaar of bereikbaar.
Als dezelfde gebruiker de HR-database probeert te bereiken, controleert de ZTNA-laag opnieuw. De financiële groep heeft geen toegang tot HR-bronnen, dus het verzoek wordt geweigerd. Geen laterale beweging. Geen blootstelling aan een breed netwerk.
Praktische integratiegids: uw IdP verbinden met een ZTNA-platform
In dit gedeelte worden de stappen doorlopen om een IdP te integreren met een ZTNA-platform. De details verschillen per leverancier, maar het patroon is consistent voor Microsoft Entra ID, Okta en Google Workspace.
Stap 1: Metagegevens uitwisselen
Download het SAML metadata XML-bestand van de IdP (of OIDC discovery URL). Dit bevat het SSO-eindpunt, de entiteit-ID en het publieke ondertekeningscertificaat van de IdP. Upload het naar de beheerconsole van uw ZTNA-platform. In ruil daarvoor configureert u de entity ID en Assertion Consumer Service (ACS) URL van het ZTNA-platform in de applicatiecatalogus van uw IdP.
Stap 2: Kenmerken in kaart brengen
Configureer de attribuutmapping tussen de IdP en het ZTNA platform. Breng minimaal e-mailadres, weergavenaam en groepslidmaatschappen in kaart. Groepslidmaatschappen zijn het belangrijkste attribuut omdat deze het toegangsbeleid aansturen. Breng uw directorygroepen (Finance, Engineering, IT-admins) in kaart voor beleid op applicatieniveau in de ZTNA-console.
Stap 3: Apparaatposturecontroles inschakelen
Configureer uw ZTNA-platform om gezondheidssignalen van apparaten naast identiteit te evalueren. Stel basisvereisten in: beheerde apparaatstatus, schijfversleuteling, actuele versie van het besturingssysteem en actieve endpointbeveiliging. Pas voor persoonlijke apparaten strengere toegangsscopes toe of beperk de toegang tot alleen browsergebaseerde applicaties.
Stap 4: SCIM-provisioning configureren
Voor omgevingen met meer dan 50 gebruikers schakelt u SCIM in om het levenscyclusbeheer van accounts te automatiseren. Dit zorgt ervoor dat toevoegingen van gebruikers, rolwijzigingen en vertrekkende gebruikers in uw IdP onmiddellijk worden weerspiegeld in alle aangesloten applicaties.
Stap 5: Certificaatrotatie beheren
SAML vertrouwensrelaties zijn afhankelijk van X.509 certificaten voor het ondertekenen van beweringen. Deze certificaten verlopen. Stel kalenderherinneringen in om ondertekeningscertificaten te roteren voordat ze verlopen. Een gemiste rotatie verbreekt de authenticatie voor elke gebruiker, wat een van de meest voorkomende oorzaken is van SSO-storingen.
Stap 6: De integratie verharden
Drie hardening stappen die token-gebaseerde aanvallen voorkomen. Schakel ondertekende verificatieverzoeken in zodat uw IdP alleen verzoeken van legitieme serviceproviders verwerkt. Configureer publieksbeperking om ervoor te zorgen dat tokens alleen geldig zijn voor uw specifieke ZTNA-tenant. Schakel voor gevoelige omgevingen (gezondheidszorg, financiën) versleutelde asserties in zodat de browser nooit ruwe identiteitsgegevens verwerkt.
Veelgemaakte fouten die IdP-integraties verbreken
Teams in het middensegment van de markt lopen vaak tegen dezelfde problemen aan tijdens de uitrol van IdP. Het voorkomen hiervan bespaart weken aan troubleshooting.
Platte groepsstructuren. Het gebruik van brede groepen zoals “Alle werknemers” doet het doel van toegang met de minste privileges teniet. Maak groepen op taakniveau die overeenkomen met specifieke applicaties. “AP Factuur Goedkeuring” is nuttiger dan “Financiële afdeling” bij het schrijven van ZTNA beleid.
Vergeten serviceaccounts. Machine-to-machine integraties omzeilen de IdP vaak volledig, door statische API-sleutels te gebruiken in plaats van authenticatie op basis van tokens. Controleer deze accounts en migreer ze waar mogelijk naar kortstondige, scoped tokens.
Geen voorwaardelijke toegangsregels. Identiteit verifiëren zonder de apparaatstatus te controleren laat een aanzienlijk gat achter. Een gecompromitteerde persoonlijke laptop met geldige referenties zou niet dezelfde toegang moeten hebben als een beheerd, versleuteld bedrijfsapparaat.
Handmatig provisioneren. Als het on- en offboarden van gebruikers nog steeds handmatige stappen in elke applicatie omvat, zullen toegangsbeoordelingen altijd achterblijven bij de realiteit. Automatiseer met SCIM.
Het verlopen van certificaten negeren. SAML ondertekeningscertificaten verlopen meestal na één tot drie jaar. Als dat gebeurt, wordt SSO direct verbroken voor alle gebruikers. Houd vervaldata bij en rouleer proactief.
Hoe IdP-integratie past binnen een SASE-architectuur
Een standalone ZTNA laag lost toegang tot applicaties op. Maar de meeste organisaties hebben ook webbeveiliging, site-to-site connectiviteit en een manier om om te gaan met apparaten die geen agents kunnen draaien nodig. Dit is waar een verenigd SASE-platform de stukken verbindt.
In een geïntegreerde SASE-architectuur voedt je IdP identiteitscontext naar meerdere handhavingspunten tegelijk. De ZTNA component gebruikt het voor toegang per applicatie. De Secure Web Gateway gebruikt het om gebruikersspecifiek web filtering beleid toe te passen. De Firewall-as-a-Service component gebruikt het voor identiteitsbewuste verkeersregels. SD-WAN zorgt ervoor dat het verkeer de juiste bestemming bereikt met consistente prestaties.
Voor apparaten die geen agent kunnen uitvoeren, zoals printers, IoT-sensoren en industriële apparatuur, biedt NIAC-hardware inline isolatie. Deze apparaten bevinden zich achter een controller die hun communicatie beperkt tot expliciet toegestane flows, waardoor agentless assets onder Zero Trust controle komen zonder dat identiteitsgebaseerde authenticatie op het apparaat zelf nodig is.
Het operationele voordeel is één console voor al deze beleidsregels. Eén plek om te bepalen wie wat kan bereiken, onder welke voorwaarden, vanaf welke apparaten. Voor kleine IT-teams is deze consolidatie het verschil tussen beheersbaar en overweldigend.
Europese nalevingscontext: Afstemming IdP en NIS2
NIS2 vereist aantoonbaar toegangsbeheer, handhaving van de laagste rechten en mogelijkheden om incidenten te beheersen. Uw IdP-integratie ondersteunt direct een aantal van deze vereisten.
Bewijs voor toegangscontrole. IdP-gebaseerd beleid met ZTNA-handhaving biedt een duidelijke registratie van wie welke applicatie heeft bezocht, wanneer, vanaf welk apparaat en met welk verificatieniveau. Dit is het bewijs dat auditors verwachten.
Evenredige toegang. GDPR vereist dat de toegang tot persoonlijke gegevens gepast en beperkt is. IdP-gedreven beleidsregels met rolgebaseerde groepen zorgen ervoor dat alleen geautoriseerd personeel bij gevoelige gegevens kan.
Beheersing van het incident. Wanneer er een inbreuk plaatsvindt, wordt door het uitschakelen van een enkel IdP-account de toegang tot alle aangesloten applicaties onmiddellijk ingetrokken. In combinatie met ZTNA’s toegangsmodel per applicatie is de straal van een gecompromitteerde identiteit beperkt tot de specifieke bronnen waartoe die identiteit was geautoriseerd.
Verantwoording. Gecentraliseerde authenticatielogs van de IdP, gecombineerd met toegangslogs van de ZTNA-laag, creëren het uniforme controlespoor dat NIS2 vereist. SCIM provisioning records voegen bewijs toe dat het beheer van de toegangslevenscyclus geautomatiseerd en tijdig is.
Hoe Jimber IdP-integratie werkbaar maakt
Het SASE-platform van Jimber integreert met grote identiteitsproviders via SAML 2.0 en OIDC. Het platform gebruikt je bestaande IdP als vertrouwensanker voor alle toegangsbeslissingen en combineert identiteitsverificatie met apparaatstatuscontroles in één beleidsengine.
In de praktijk betekent dit dat uw directorygroepen de toegang tot specifieke applicaties regelen via ZTNA, webfilterbeleid via de Secure Web Gateway en netwerksegmentatie tussen sites via SD-WAN. Agentless apparaten worden geïsoleerd achter NIAC-hardware en het verkeer wordt beperkt tot expliciet toegestane flows. Dit alles wordt beheerd vanuit één cloudconsole met transparante prijzen en ondersteuning voor meerdere huurders voor MSP’s.
De integratie volgt de hierboven beschreven stappen: metadata-uitwisseling, attribuutmapping, postureconfiguratie en SCIM-provisioning. De meeste teams in het middensegment van de markt voltooien de eerste installatie in dagen, niet in weken, omdat het platform is ontworpen voor een snelle ingebruikname zonder complexe migratieprojecten.
FAQ
Welke identiteitsproviders werken met ZTNA-platforms?
De meeste ZTNA-platforms ondersteunen elke IdP die SAML 2.0 of OIDC implementeert. Microsoft Entra ID, Okta, Google Workspace en Ping Identity zijn de meest voorkomende in de Europese middenmarkt.
Moet ik mijn huidige IdP vervangen om Zero Trust in te voeren?
Nee. ZTNA-platforms maken verbinding met uw bestaande IdP. Het doel is om uw huidige directory- en authenticatie-infrastructuur te gebruiken als vertrouwensanker voor een meer granulair toegangsbeleid per applicatie.
Hoe verschilt SAML in de praktijk van OIDC?
SAML maakt gebruik van XML-gebaseerde asserties en past goed bij legacy enterprise webapplicaties. OIDC gebruikt lichtgewicht JSON tokens en is beter geschikt voor cloud-native en mobiele applicaties. De meeste organisaties gebruiken beide protocollen vanuit dezelfde IdP.
Welke rol speelt SCIM in Zero Trust-toegang?
SCIM automatiseert de provisioning en deprovisioning van gebruikers over applicaties heen. Het zorgt ervoor dat toegangswijzigingen in uw IdP onmiddellijk worden gereflecteerd, wat nodig is voor NIS2-compliance en het risico van verouderde accounts vermindert.
Kunnen kleine IT-teams IdP-integratie beheren zonder een speciale IAM-specialist?
Ja. Moderne ZTNA-platforms vereenvoudigen de integratie met metadata-uitwisseling, attribuutmapping en beleidsconfiguratie. Een team dat bekend is met de beheerconsole van hun IdP kan de installatie voltooien. Platformen met één beheerconsole verminderen de lopende overhead aanzienlijk.
Hoe werkt device posture naast IdP-authenticatie?
De IdP verifieert de identiteit van de gebruiker. Het ZTNA-platform evalueert de beveiligingsstatus van het apparaat. Toegang wordt alleen verleend als beide controles slagen. Dit voorkomt dat een geldig credential op een gecompromitteerd apparaat gevoelige applicaties kan bereiken.
Klaar om van je identity provider het vertrouwensanker te maken voor elke toegangsbeslissing? Boek een demo en zie hoe IdP-integratie werkt in Jimbers SASE-console.
