Het artikel betoogt dat het Security Assertion Markup Language (SAML) protocol verouderd is en vervangen moet worden door OpenID Connect (OIDC). De auteur beargumenteert dat SAML lijdt onder een 'design-by-committee' aanpak, waarbij vier verschillende protocollen werden samengevoegd tot een onnodig complex 'kitchen-sink' ontwerp.
De belangrijkste technische gebreken die worden benoemd zijn:
- De XML-basis: XML is complexer dan JSON en gevoelig voor diverse security-bugs zoals XXE en XML Signature Wrapping (XSW).
- Canonicalisatie (C14N): De noodzaak om XML-structuren consistent te maken voor hashing leidt tot parser-fouten en bypasses.
- Enveloped signatures: De integratie van de handtekening in de payload maakt veilige aanpassingen lastig.
- Verstijving: Het protocol is niet meegegroeid met moderne webarchitecturen, mobiele apps en cloud-native netwerktopologieën.
De auteur concludeert dat OIDC een superieur alternatief is en adviseert zowel Service Providers als Identity Providers om een transitieplan naar OIDC te implementeren.
SAML: Een fractaal van slecht ontwerp
Geboren in de academische wereld en grootgebracht in corporate IT-afdelingen, blijft het authenticatieprotocol Security Assertion Markup Language (SAML) een vast onderdeel van deze organisaties. Het is echter tijd dat het met pensioen gaat. Met de opkomst van software-as-a-service (SaaS) bedrijven eind jaren 2000 hadden IT-afdelingen een manier nodig om gebruikers te authenticeren bij veel nieuwe webdiensten. SAML en de opkomende single sign-on (SSO) industrie vervulden deze behoefte.
SAML bezwijkt echter onder het gewicht van zijn eigen complexiteit. Het is tijd om het uit te faseren en over te stappen op moderne alternatieven zoals OpenID Connect (OIDC). In dit artikel onderzoek ik de "design-by-committee" oorsprong van SAML, de weg die het aflegde binnen academische en zakelijke omgevingen, de langzame desintegratie door de security research community, en de (hopelijk) aanstaande vervanging door nieuwere protocollen.
SAML 101
"Het verraderlijke aan SAML is dat het grotendeels eenvoudig te begrijpen is, maar het is gebouwd op een fundament van zand, bottenstof en as; het werkt... mits je ervan uitgaat dat XML-handtekeningvalidatie betrouwbaar is. Maar XML-handtekeningvalidatie is diep vervloekt en zo gecompliceerd dat de meeste actuele SAML-implementaties gebruikmaken van libxmlsec, een grillige C-codebase die niemand leest."
— Thomas Ptacek, 2023
SAML en de geboorte van de SSO-industrie
Volgens Wikipedia is "SAML een op XML gebaseerde markupltal voor beveiligingsbeweringen (security assertions)". Het werd in 2002 gecreëerd door het Security Services Technical Committee (SSTC) van de Organization for the Advancement of Structured Information Standards (OASIS).
Naar moderne maatstaven is dit geen ideale start. XML is, ondanks enkele goede eigenschappen, behoorlijk complex vergeleken met nieuwere alternatieven zoals JSON. Bovendien is een comité van subcomités die vergaderingen houden vaak een recept voor een "kitchen-sink" ontwerp (alles erin gooien, zoals bij de watervalmethode). Dat is precies wat er gebeurde: er zijn vier verschillende XML-gebaseerde beveiligingsprotocollen in één samengevoegd:
- S2ML (Security Services Markup Language) van Netegrity
- AuthXML van Securant
- X-TASS (XML Trust Assertion Service Specification) van VeriSign
- ITML (Information Technology Markup Language) van Jamcracker
De behoefte aan zo'n protocol was echter onmiskenbaar. Terwijl het internet verschoof van Web 1.0 naar Web 2.0, hadden organisaties een eenvoudige manier nodig om zich te authenticeren bij diverse webdiensten. De academische wereld was hier de grootste drijfveer achter:
- Central Authentication Service (CAS) in 2002 aan Yale.
- Shibboleth IdP in 2003 door Internet2 (een consortium van onderzoeksuniversiteiten).
- ADFS in 2003 door Microsoft.
- simpleSAMLphp rond 2007 door Uninett (een Noors staatsbedrijf met nauwe banden met de academische wereld).
Zodra deze basislaag van protocollen en academische bewijsvoering was gevestigd, nam de commerciële industrie het over en ontstond er een miljardenindustrie. Bedrijven als Ping Identity (2002), OneLogin (2009), Okta (2009) en Duo Security (2010) werden essentieel gebouwd op het SAML-protocol.
Een barst in het pantser
XML Signature Wrapping (XSW) aanvallen zijn de achilleshiel van SAML. Hoewel er al eerder onderzoek was naar signature wrapping (2005, 2008, 2009) en SAML (2008), was het artikel "On Breaking SAML: Be Whoever You Want to Be" (2012) bepalend. Dit onderzoek testte theorie tegen praktijk en resulteerde in een geautomatiseerde manier om XSW-aanvallen te controleren.
Ondanks dat XSW al in 2012 centraal stond, is het vandaag de dag nog steeds aanwezig. Om te begrijpen waarom dit niet simpelweg gefixt kan worden, moeten we kijken naar de wankele basis waarop SAML is gebouwd: XML.
XML heeft een problematische staat van dienst op het gebied van security. Ontwikkelaars uit de jaren 90 zullen deze bug-klassen herkennen, maar ze zijn nog steeds relevant:
- XXE (XML External Entity)
- Entity expansion ("billion laughs")
- DTD retrieval (SSRF)
- XPath/XQuery/XInclude/XSLT/CDATA injectie
Een SAML-bibliotheek moet al deze problemen afhandelen voordat het überhaupt aan de eigenlijke SAML-functionaliteit toekomt. Daarnaast is er de pure complexiteit: XML kent tags, elementen, attributen, comments, namespaces, schema's, CDATA en DOCTYPEs. JSON daarentegen gebruikt essentieel alleen keys, values, objecten en lijsten. Complexiteit staat over het algemeen haaks op veiligheid, wat SAML maakt tot een fractaal van slecht ontwerp.
Een fractaal van slecht ontwerp
Hieronder volgen vijf fundamentele gebreken die volgens mij fataal zijn voor de levensvatbaarheid van SAML op de lange termijn.
1. Gebouwd op XML
Zoals vermeld is XML complex. Dit was destijds niet per se de schuld van het comité; XML was de standaard van dat moment. JSON werd weliswaar in 2001 "ontdekt", maar dat was precies wanneer het SAML-comité samenkwam. Ze zouden waarschijnlijk niet kiezen voor een experimenteel formaat dat gericht was op JavaScript, terwijl zij voornamelijk in Java schreven.
2. Canonicalisatie (C14N)
Canonicalisatie is het proces waarbij een chaotische XML-structuur wordt omgezet naar een consistente weergave, zodat er een betrouwbare hash van kan worden gemaakt. Als de Service Provider (SP) en de Identity Provider (IdP) het niet eens worden over de representatie van de XML-data, komen de bytes niet overeen, matcht de handtekening niet en faalt de authenticatie.
Canonicalisatie-bugs maakten onder andere de XML comment bypass van Kelby Ludwig in 2018 mogelijk. Veel moderne SAML-aanvallen maken gebruik van parser differentials of "round-trip" bugs, zoals blijkt uit diverse disclosures tussen 2020 en 2025 (o.a. bij GitHub Enterprise en Go's standaardbibliotheek).
3. Omhulde handtekeningen (Enveloped signatures)
Bij enveloped signatures wordt de handtekening in de data-payload geplaatst die ondertekend wordt. Dit is problematisch omdat het zeer moeilijk is om een byte-voor-byte, canoniek equivalente representatie van data te krijgen terwijl je die data tegelijkertijd aanpast.
Ter vergelijking: bij een JWT (JSON Web Token) is de handtekening losgekoppeld (detached) van de JSON-payload en gescheiden door een punt (.). Bij SAML is het Signature-element ingevoegd in het Assertion-element.
4. "Kitchen-sink" ontwerp
Dit is een schending van het YAGNI-principe (You Ain't Gonna Need It). Hoewel de gebruikte delen van de specificatie in 20 jaar zijn veranderd, gebruiken 99% van de moderne SAML-implementaties een zeer vergelijkbare datastructuur en een klein subset van de specificatie. Ongeveer 90% van de specificatie wordt in de praktijk vermeden. Dit voegt enorme complexiteit toe voor functies die nauwelijks worden gebruikt.
5. Verstijving (Ossification)
SAML is ontworpen in een ander tijdperk en is niet adequaat bijgewerkt. Dit uit zich in:
- Transport: OIDC gaat uit van HTTP, terwijl SAML transport-onafhankelijk is. Hoewel HTTP-bindings het meest voorkomen, betekent deze flexibiliteit dat er meer fouten kunnen ontstaan. HTTPS stelt OIDC in staat om versleutelde, vertrouwde communicatie over te laten aan de transportlaag.
- Netwerktopologie: OIDC gaat uit van een verbonden netwerktopologie waarbij de OpenID Provider (OP) en Relying Party (RP) direct kunnen communiceren. Dit vermindert de druk op de payload, omdat informatie via een backchannel kan worden uitgewisseld. SAML is ontworpen voor een tijd van VPN's en strikte netwerksegmentatie, waarbij alle informatie in de payload moest zitten als directe communicatie niet mogelijk was.
- Ontwikkelmethode: OIDC is organisch gegroeid via tientallen specificaties en RFC's die specifieke behoeften oplossen (vergelijkbaar met de agile methode). SAML werd grotendeels vooraf ontworpen (waterfall), waardoor het niet kon anticiperen op de revoluties van mobiele apps, SPA's (Single Page Applications) en IoT.
Alle wegen leiden naar OIDC
Geen enkel protocol is perfect, maar OIDC is de superieure oplossing. De enige scenario's waarin SAML een voordeel had, waren netwerken waar de SP en IdP niet direct konden communiceren, maar OIDC's implicit flow met form post biedt dezelfde mogelijkheden.
Advies voor Service Providers (SP): Stop met het implementeren van SAML. Ondersteun OIDC. Bedrijven als Fly.io en Tailscale doen dit al.
Advies voor Identity Providers (IdP): Het overstappen van SAML kan een lang proces zijn, maar het is noodzakelijk. Ontwikkel een uitfaseringsplan: 1 Communiceer het plan naar klanten. 2 Stop met het onboarden van nieuwe klanten via SAML. 3 Bied bestaande SAML-klanten equivalente OIDC-configuraties aan. 4 Stel een definitieve stopdatum (sunset date) vast.
SAML heeft een goede loopbaan van 25 jaar gehad. Het heeft de SSO-industrie doen ontstaan en miljarden dollars aan economische impact gecreëerd. We kunnen de makers dankbaar zijn, maar het protocol dient nu vooral als een waardevolle casestudy in protocolontwerp en evolutie binnen een dynamische tech-industrie.
SAML: Een fractaal van slecht ontwerp
Geboren in de academische wereld en grootgebracht in corporate IT-afdelingen, blijft het authenticatieprotocol Security Assertion Markup Language (SAML) een vast onderdeel van deze organisaties. Het is echter tijd dat het met pensioen gaat. Met de opkomst van software-as-a-service (SaaS) bedrijven eind jaren 2000 hadden IT-afdelingen een manier nodig om gebruikers te authenticeren bij veel nieuwe webdiensten. SAML en de opkomende single sign-on (SSO) industrie vervulden deze behoefte.
SAML bezwijkt echter onder het gewicht van zijn eigen complexiteit. Het is tijd om het uit te faseren en over te stappen op moderne alternatieven zoals OpenID Connect (OIDC). In dit artikel onderzoek ik de "design-by-committee" oorsprong van SAML, de weg die het aflegde binnen academische en zakelijke omgevingen, de langzame desintegratie door de security research community, en de (hopelijk) aanstaande vervanging door nieuwere protocollen.
SAML 101
"Het verraderlijke aan SAML is dat het grotendeels eenvoudig te begrijpen is, maar het is gebouwd op een fundament van zand, bottenstof en as; het werkt... mits je ervan uitgaat dat XML-handtekeningvalidatie betrouwbaar is. Maar XML-handtekeningvalidatie is diep vervloekt en zo gecompliceerd dat de meeste actuele SAML-implementaties gebruikmaken van libxmlsec, een grillige C-codebase die niemand leest."
— Thomas Ptacek, 2023
SAML en de geboorte van de SSO-industrie
Volgens Wikipedia is "SAML een op XML gebaseerde markupltal voor beveiligingsbeweringen (security assertions)". Het werd in 2002 gecreëerd door het Security Services Technical Committee (SSTC) van de Organization for the Advancement of Structured Information Standards (OASIS).
Naar moderne maatstaven is dit geen ideale start. XML is, ondanks enkele goede eigenschappen, behoorlijk complex vergeleken met nieuwere alternatieven zoals JSON. Bovendien is een comité van subcomités die vergaderingen houden vaak een recept voor een "kitchen-sink" ontwerp (alles erin gooien, zoals bij de watervalmethode). Dat is precies wat er gebeurde: er zijn vier verschillende XML-gebaseerde beveiligingsprotocollen in één samengevoegd:
- S2ML (Security Services Markup Language) van Netegrity
- AuthXML van Securant
- X-TASS (XML Trust Assertion Service Specification) van VeriSign
- ITML (Information Technology Markup Language) van Jamcracker
De behoefte aan zo'n protocol was echter onmiskenbaar. Terwijl het internet verschoof van Web 1.0 naar Web 2.0, hadden organisaties een eenvoudige manier nodig om zich te authenticeren bij diverse webdiensten. De academische wereld was hier de grootste drijfveer achter:
- Central Authentication Service (CAS) in 2002 aan Yale.
- Shibboleth IdP in 2003 door Internet2 (een consortium van onderzoeksuniversiteiten).
- ADFS in 2003 door Microsoft.
- simpleSAMLphp rond 2007 door Uninett (een Noors staatsbedrijf met nauwe banden met de academische wereld).
Zodra deze basislaag van protocollen en academische bewijsvoering was gevestigd, nam de commerciële industrie het over en ontstond er een miljardenindustrie. Bedrijven als Ping Identity (2002), OneLogin (2009), Okta (2009) en Duo Security (2010) werden essentieel gebouwd op het SAML-protocol.
Een barst in het pantser
XML Signature Wrapping (XSW) aanvallen zijn de achilleshiel van SAML. Hoewel er al eerder onderzoek was naar signature wrapping (2005, 2008, 2009) en SAML (2008), was het artikel "On Breaking SAML: Be Whoever You Want to Be" (2012) bepalend. Dit onderzoek testte theorie tegen praktijk en resulteerde in een geautomatiseerde manier om XSW-aanvallen te controleren.
Ondanks dat XSW al in 2012 centraal stond, is het vandaag de dag nog steeds aanwezig. Om te begrijpen waarom dit niet simpelweg gefixt kan worden, moeten we kijken naar de wankele basis waarop SAML is gebouwd: XML.
XML heeft een problematische staat van dienst op het gebied van security. Ontwikkelaars uit de jaren 90 zullen deze bug-klassen herkennen, maar ze zijn nog steeds relevant:
- XXE (XML External Entity)
- Entity expansion ("billion laughs")
- DTD retrieval (SSRF)
- XPath/XQuery/XInclude/XSLT/CDATA injectie
Een SAML-bibliotheek moet al deze problemen afhandelen voordat het überhaupt aan de eigenlijke SAML-functionaliteit toekomt. Daarnaast is er de pure complexiteit: XML kent tags, elementen, attributen, comments, namespaces, schema's, CDATA en DOCTYPEs. JSON daarentegen gebruikt essentieel alleen keys, values, objecten en lijsten. Complexiteit staat over het algemeen haaks op veiligheid, wat SAML maakt tot een fractaal van slecht ontwerp.
Een fractaal van slecht ontwerp
Hieronder volgen vijf fundamentele gebreken die volgens mij fataal zijn voor de levensvatbaarheid van SAML op de lange termijn.
1. Gebouwd op XML
Zoals vermeld is XML complex. Dit was destijds niet per se de schuld van het comité; XML was de standaard van dat moment. JSON werd weliswaar in 2001 "ontdekt", maar dat was precies wanneer het SAML-comité samenkwam. Ze zouden waarschijnlijk niet kiezen voor een experimenteel formaat dat gericht was op JavaScript, terwijl zij voornamelijk in Java schreven.
2. Canonicalisatie (C14N)
Canonicalisatie is het proces waarbij een chaotische XML-structuur wordt omgezet naar een consistente weergave, zodat er een betrouwbare hash van kan worden gemaakt. Als de Service Provider (SP) en de Identity Provider (IdP) het niet eens worden over de representatie van de XML-data, komen de bytes niet overeen, matcht de handtekening niet en faalt de authenticatie.
Canonicalisatie-bugs maakten onder andere de XML comment bypass van Kelby Ludwig in 2018 mogelijk. Veel moderne SAML-aanvallen maken gebruik van parser differentials of "round-trip" bugs, zoals blijkt uit diverse disclosures tussen 2020 en 2025 (o.a. bij GitHub Enterprise en Go's standaardbibliotheek).
3. Omhulde handtekeningen (Enveloped signatures)
Bij enveloped signatures wordt de handtekening in de data-payload geplaatst die ondertekend wordt. Dit is problematisch omdat het zeer moeilijk is om een byte-voor-byte, canoniek equivalente representatie van data te krijgen terwijl je die data tegelijkertijd aanpast.
Ter vergelijking: bij een JWT (JSON Web Token) is de handtekening losgekoppeld (detached) van de JSON-payload en gescheiden door een punt (.). Bij SAML is het Signature-element ingevoegd in het Assertion-element.
4. "Kitchen-sink" ontwerp
Dit is een schending van het YAGNI-principe (You Ain't Gonna Need It). Hoewel de gebruikte delen van de specificatie in 20 jaar zijn veranderd, gebruiken 99% van de moderne SAML-implementaties een zeer vergelijkbare datastructuur en een klein subset van de specificatie. Ongeveer 90% van de specificatie wordt in de praktijk vermeden. Dit voegt enorme complexiteit toe voor functies die nauwelijks worden gebruikt.
5. Verstijving (Ossification)
SAML is ontworpen in een ander tijdperk en is niet adequaat bijgewerkt. Dit uit zich in:
- Transport: OIDC gaat uit van HTTP, terwijl SAML transport-onafhankelijk is. Hoewel HTTP-bindings het meest voorkomen, betekent deze flexibiliteit dat er meer fouten kunnen ontstaan. HTTPS stelt OIDC in staat om versleutelde, vertrouwde communicatie over te laten aan de transportlaag.
- Netwerktopologie: OIDC gaat uit van een verbonden netwerktopologie waarbij de OpenID Provider (OP) en Relying Party (RP) direct kunnen communiceren. Dit vermindert de druk op de payload, omdat informatie via een backchannel kan worden uitgewisseld. SAML is ontworpen voor een tijd van VPN's en strikte netwerksegmentatie, waarbij alle informatie in de payload moest zitten als directe communicatie niet mogelijk was.
- Ontwikkelmethode: OIDC is organisch gegroeid via tientallen specificaties en RFC's die specifieke behoeften oplossen (vergelijkbaar met de agile methode). SAML werd grotendeels vooraf ontworpen (waterfall), waardoor het niet kon anticiperen op de revoluties van mobiele apps, SPA's (Single Page Applications) en IoT.
Alle wegen leiden naar OIDC
Geen enkel protocol is perfect, maar OIDC is de superieure oplossing. De enige scenario's waarin SAML een voordeel had, waren netwerken waar de SP en IdP niet direct konden communiceren, maar OIDC's implicit flow met form post biedt dezelfde mogelijkheden.
Advies voor Service Providers (SP): Stop met het implementeren van SAML. Ondersteun OIDC. Bedrijven als Fly.io en Tailscale doen dit al.
Advies voor Identity Providers (IdP): Het overstappen van SAML kan een lang proces zijn, maar het is noodzakelijk. Ontwikkel een uitfaseringsplan: 1 Communiceer het plan naar klanten. 2 Stop met het onboarden van nieuwe klanten via SAML. 3 Bied bestaande SAML-klanten equivalente OIDC-configuraties aan. 4 Stel een definitieve stopdatum (sunset date) vast.
SAML heeft een goede loopbaan van 25 jaar gehad. Het heeft de SSO-industrie doen ontstaan en miljarden dollars aan economische impact gecreëerd. We kunnen de makers dankbaar zijn, maar het protocol dient nu vooral als een waardevolle casestudy in protocolontwerp en evolutie binnen een dynamische tech-industrie.
Groetjes,