Soevereine SSO-identiteitsfederatie is het geheel van technische en organisatorische maatregelen waarmee een organisatie volledige zeggenschap behoudt over haar identiteitsinfrastructuur, zonder afhankelijk te zijn van een externe cloudprovider. In de context van SAML 2.0 en OpenID Connect (OIDC) betekent dit: een on-premise of zelf gehoste identiteitsprovider die alle authenticatie- en autorisatiebeslissingen autonoom neemt, controleerbaar logt en nooit persoonsgegevens doorstuurt naar systemen buiten de eigen juridische jurisdictie.
Waarom Azure AD / Entra ID een soevereiniteitsprobleem vormt
Azure AD (nu Entra ID) is voor veel organisaties de standaard geworden voor SSO, maar wie het gebruikt als centrale identiteitsprovider, plaatst de sleutels tot zijn volledige digitale omgeving bij een bedrijf dat onder Amerikaanse jurisdictie valt.
De Amerikaanse CLOUD Act (2018) verplicht Amerikaanse technologiebedrijven om op bevel van de Amerikaanse overheid gegevens te verstrekken, ongeacht de fysieke opslaglocatie in Europa. Dit geldt ook voor authenticatielogs, gebruikersdirectory’s en sessietokens die via Entra ID worden gegenereerd. De Patriot Act biedt een vergelijkbare bevoegdheid voor inlichtingendiensten, met bovendien een verbod op kennisgeving aan de betrokken organisatie.
Concreet betekent dit dat een rechtbank of overheidsinstantie in de VS toegang kan eisen tot de identiteitslaag van een Nederlandse gemeente, rechtbank of zorginstelling, zonder dat die organisatie dit weet of kan voorkomen. Voor organisaties die vallen onder de Nederlandse BIO2 (Baseline Informatiebeveiliging Overheid versie 2) of de Europese NIS-2-richtlijn is dit een structureel complianceprobleem, niet slechts een theoretisch risico.
Bovendien creëert de centrale positie van Entra ID een enkelvoudig storingspunt: een storing bij Microsoft, zoals de wereldwijde CrowdStrike-gerelateerde uitval in juli 2024, kan de volledige authenticatieketen van een organisatie platleggen als er geen eigen fallback bestaat.
Een volledig zelfbeheerde identiteitsfederatie bouwen
De open-source markt biedt volwaardige alternatieven die SAML 2.0 (OASIS-standaard) en OpenID Connect / OAuth 2.0 volledig ondersteunen en on-premise draaien zonder externe afhankelijkheden.
Keycloak
Keycloak is het meest volwassen open-source IAM-platform en wordt actief onderhouden door Red Hat. Het ondersteunt SAML 2.0, OIDC, LDAP- en Active Directory-koppeling, rolgebaseerd toegangsbeheer (RBAC), attributegebaseerd toegangsbeheer (ABAC) en een volledig configureerbare MFA-stack. Keycloak kan federeren met externe identiteitsproviders via standaard SAML-metadata of OIDC-discovery-endpoints, waardoor B2B-federatie zonder hyperscaler-tussenkomst mogelijk is. De administratie-API maakt automatisering van accountprovisioning en deprovisioning via SCIM 2.0 of eigen scripts mogelijk.
Authentik
Authentik is een modernere Python/Django-gebaseerde identiteitsprovider die bijzonder geschikt is voor containeromgevingen (Kubernetes, Docker). Het biedt een visuele flow-editor waarmee authenticatiestromen, MFA-stappen en onboardingprocessen zonder codering te configureren zijn. Authentik ondersteunt eveneens SAML 2.0 en OIDC en heeft ingebouwde ondersteuning voor provisioning via LDAP-uitrol en SCIM.
Shibboleth
Shibboleth Identity Provider is de de-factostandaard in het hoger onderwijs en onderzoek, bijzonder sterk in SAML 2.0-federaties zoals SURFconext. Voor instellingen die al actief zijn in onderwijsfederaties is Shibboleth de meest compatibele keuze, al vraagt het meer beheerinspanning dan Keycloak of Authentik.
| Platform | SAML 2.0 | OIDC | SCIM | Sterke punten | Geschikt voor |
|---|---|---|---|---|---|
| Keycloak | Ja | Ja | Via extensie | Rijke feature-set, grote community, Red Hat support | Overheid, enterprise, zorg |
| Authentik | Ja | Ja | Ingebouwd | Moderne UX, container-native, visuele flows | Cloud-native, DevOps-omgevingen |
| Shibboleth IdP | Ja | Beperkt | Nee | Diep SAML-ecosysteem, eduGAIN/SURFconext | Onderwijs, onderzoek |
NIS-2 artikel 21 en BIO2: de juridische minimumvereisten
Zowel NIS-2 als BIO2 stellen expliciete eisen aan identiteits- en toegangsbeheer. Deze eisen zijn geen inspanningsverplichting maar afdwingbare normen met bijbehorende boetes en aansprakelijkheid voor bestuurders.
NIS-2 artikel 21 lid 2(i) verplicht alle essentiële en belangrijke entiteiten tot het toepassen van multi-factor authenticatie of continue authenticatie, beveiligd berichtenverkeer, en noodcommunicatiesystemen. ENISA formuleert het als volgt:
“Artikel 21 van NIS-2 verplicht entiteiten expliciet tot het gebruik van multi-factor authenticatie en toegangscontrole als basisbeveiligingsmaatregelen. Dit is geen aanbeveling maar een juridische verplichting.” (ENISA, NIS-2 Implementation Guidance)
De Nederlandse BIO2 vereist aanvullend dat toegangsrechten periodiek worden gereviewed, dat accounts van vertrokken medewerkers binnen een gedefinieerde termijn worden uitgeschakeld, en dat het least-privilege-principe aantoonbaar wordt toegepast. Beide kaders sluiten goed aan op de NIST SP 800-63B Digital Identity Guidelines, die drie authenticatieniveaus (AAL1 t/m AAL3) definiëren op basis van risicoprofiel. Voor systemen met verhoogd risico, zoals overheidssystemen met persoonsgegevens, is AAL2 (MFA met phishing-resistente tweede factor) het minimumniveau.
Statistiek: Volgens het Verizon Data Breach Investigations Report 2023 was bij 86% van de datalekken een gecompromitteerde of gestolen inloggegevens de initiële aanvalsvector. Dit onderstreept waarom NIS-2 MFA als verplichte maatregel opneemt.
MFA, smartcards, PIV-certificaten en het PQC-transitiepad naar ML-DSA
Een soevereine SSO-omgeving zonder sterke authenticatie is onvolledig. Keycloak en Authentik ondersteunen beide TOTP (RFC 6238), WebAuthn/FIDO2-tokens en certificaatgebaseerde authenticatie via smartcards en PIV-kaarten (Personal Identity Verification, NIST SP 800-73).
Smartcard-authenticatie via PKCS#11 kan worden geïntegreerd in de Keycloak-authenticatieflow, waarbij het X.509-certificaat op de kaart wordt geverifieerd tegen een interne of organisatie-eigen PKI. Dit elimineert wachtwoorden volledig uit de SSO-flow en voldoet aan AAL3 uit NIST SP 800-63B.
De post-quantum transitie voegt een extra dimensie toe. De huidige RSA- en ECDSA-algoritmen die worden gebruikt voor certificaatondertekening en token-signing in SAML-assertions en OIDC-JWTs zijn kwetsbaar voor een voldoende krachtige kwantumcomputer. NIST heeft in augustus 2024 ML-DSA (Module-Lattice-Based Digital Signature Algorithm, eerder bekend als CRYSTALS-Dilithium) gestandaardiseerd als FIPS 204. Organisaties zouden nu moeten inventariseren welke cryptografische primitieven in hun IAM-infrastructuur worden gebruikt en een migratiepad plannen:
- Audit van alle certificaatprofielen en token-signing-sleutels in de huidige IdP.
- Hybride ondertekening inschakelen (klassiek + ML-DSA) zodra bibliotheken dit ondersteunen, zodat achterwaartse compatibiliteit behouden blijft.
- Volledige migratie naar ML-DSA-ondertekende assertions en certificaten wanneer de Java- en PKI-ecosystemen FIPS 204 volledig implementeren.
Bart Preneel, hoogleraar cryptografie aan de KU Leuven, stelt: “Identiteitsbeheer is de nieuwe perimeter. Wie de identiteitsinfrastructuur niet zelf beheert, heeft geen controle over wie zijn systemen binnenkomt.” Dit geldt des te meer in een post-quantum landschap, waarbij de cryptografische basis van die controle zelf onder druk staat.
B2B-identiteitsfederatie zonder hyperscaler-tussenkomst
Organisaties in ketens, zoals gemeenten die samenwerken met uitvoeringsinstanties, of advocatenkantoren die aansluiten op rechtbanksystemen, hebben behoefte aan federatieve SSO waarbij geen van de partijen afhankelijk is van een externe cloudprovider.
Dit is technisch volledig realiseerbaar via directe SAML 2.0-metadata-uitwisseling of via een gedeelde federatiemakelaar. In het onderwijs is SURFconext (beheerd door SURF) hiervan een bewezen voorbeeld: een Nederlandse federatiehub die SAML-metadata beheert voor honderden instellingen zonder dat een commerciële hyperscaler in de vertrouwensketen zit.
Voor sectorfederaties buiten het onderwijs kan een vergelijkbare aanpak worden gevolgd. Elke deelnemende organisatie beheert een eigen Keycloak- of Authentik-instantie, publiceert SAML-metadata via een beveiligd endpoint, en sluit aan op een gezamenlijk beheerde federatiehub. Vertrouwensrelaties worden vastgelegd in bilaterale of multilaterale metadata-overeenkomsten, vergelijkbaar met de eduGAIN-federatie op Europees niveau.
Lifecycle-beheer: least privilege, provisioning en het AVG-recht op vergetelheid
Een soevereine IAM-omgeving is pas compleet als de volledige levenscyclus van accounts gestructureerd is ingericht. Dit omvat provisioning bij indiensttreding, rolwijzigingen tijdens de loopbaan en volledige deprovisioning bij uitdiensttreding.
Het least-privilege-principe vereist dat gebruikers alleen de minimaal noodzakelijke toegangsrechten krijgen. In Keycloak wordt dit geïmplementeerd via realm-rollen, client-rollen en groepen, waarbij roluitgifte aan workflows of HR-systemen kan worden gekoppeld via SCIM 2.0 of de Keycloak Admin API. Periodieke access reviews, zoals vereist door BIO2 en ISO 27001, kunnen worden geautomatiseerd via rapporten uit de Keycloak-database of via koppeling met een IGA-tool (Identity Governance and Administration).
AVG artikel 17 (recht op vergetelheid) vereist dat bij een verzoek tot verwijdering alle persoonsgebonden accountdata worden gewist. In een federatieve omgeving betekent dit ook: het intrekken van actieve SAML-sessies bij alle service providers, het verwijderen van OIDC-refresh-tokens, en het anonimiseren of verwijderen van authenticatielogs conform de vastgestelde bewaartermijnen. Dit proces moet gedocumenteerd en reproduceerbaar zijn, zodat het bij een AVG-audit aantoonbaar is uitgevoerd.
Statistiek: Meer dan 30 landen hebben NIST SP 800-208 en de bijbehorende post-quantum standaarden aangewezen als basis voor hun overheidsmigratie (NIST, 2024), wat aangeeft dat de overgang van klassieke PKI naar PQC-certificaten geen optionele exercitie meer is voor overheidsorganisaties.
FAQ: soevereine SSO en identiteitsfederatie
Is Keycloak geschikt voor productieomgevingen in de publieke sector?
Ja. Keycloak wordt actief onderhouden door Red Hat en wordt wereldwijd ingezet door overheidsorganisaties. Het ondersteunt SAML 2.0, OpenID Connect, LDAP-koppeling, MFA en rolgebaseerd toegangsbeheer, en draait volledig on-premise zonder externe afhankelijkheden.
Wat is het verschil tussen SAML 2.0 en OIDC voor federatieve SSO?
SAML 2.0 is de OASIS-standaard die van oudsher wordt gebruikt in enterprise- en overheidsomgevingen met XML-gebaseerde assertions. OIDC bouwt voort op OAuth 2.0 en gebruikt JSON/JWT-tokens; het is moderner en beter geschikt voor REST-API-integraties en mobiele toepassingen. Platforms zoals Keycloak ondersteunen beide protocollen naast elkaar.
Wat zijn de gevolgen van de CLOUD Act voor organisaties die Azure AD gebruiken?
De CLOUD Act (2018) verplicht Amerikaanse technologiebedrijven om op bevel toegang te verlenen tot data die zij bewaren, ongeacht de fysieke opslaglocatie. Organisaties die Entra ID gebruiken, geven daarmee potentieel toegang tot authenticatiegegevens, sessietokens en directorydata aan een partij die onder deze wet valt.
Hoe verhoudt het AVG-recht op vergetelheid zich tot identiteitsbeheer?
AVG artikel 17 vereist dat persoonsgebonden accountgegevens volledig verwijderbaar zijn. Dit omvat in een soevereine IAM-omgeving ook het intrekken van actieve sessies bij alle federatiepartners, het verwijderen van refresh-tokens en het anonimiseren van logs conform bewaartermijnen.
Wanneer is ML-DSA verplicht en welke systemen ondersteunen het al?
ML-DSA is gestandaardiseerd als NIST FIPS 204 in augustus 2024. Verplichtende Europese wetgeving is nog in voorbereiding, maar ANSSI en BSI adviseren al concrete migratiepaden. Volledige Keycloak-ondersteuning wordt verwacht zodra Java-ecosysteembibliotheken FIPS 204 volledig implementeren; via de BouncyCastle-bibliotheek zijn al experimenten mogelijk.
