SAML

SAML (Security Assertion Markup Language) ist ein XML-basierter Single-Sign-On-Standard (SSO), der 2005 von OASIS veröffentlicht wurde. Stark genutzt bei B2B-Integrationen im Enterprise-Umfeld – Okta, Ping Identity, Microsoft AD FS, Google Workspace, jedes SaaS, das an Großunternehmen verkauft.

Das Modell: ein Identity Provider (IdP, z. B. Okta) authentifiziert den Nutzer. Der Nutzer landet bei einem Service Provider (SP, z. B. Salesforce) mit einer signierten SAML-Assertion, die belegt, wer er ist. Der SP prüft die Signatur gegen den öffentlichen Schlüssel des IdP und vertraut der Aussage.

SAML vs. OAuth2/OIDC: SAML ist älter, XML-basiert und für Enterprise-SSO entworfen. OAuth/OIDC sind JSON-basiert, ursprünglich für delegierte Autorisierung gedacht (“erlaube dieser App, mein Gmail zu lesen”) und später auf Authentifizierung erweitert (OIDC). Neue Enterprise-Integrationen nutzen zunehmend OIDC; bestehende Enterprise-SaaS verlangen oft weiterhin SAML, weil die IdPs der Kunden es erfordern.

Die XML-Signatur-Spezifikation, die SAML verwendet, ist notorisch fehleranfällig – XML-Signature-Wrapping-Angriffe existieren bei vielen Implementierungen. Moderne Bibliotheken (z. B. python-saml, die von OneLogin) behandeln dies standardmäßig korrekt; eine eigene Implementierung ist eine schlechte Idee.

SAML-Bindings — wie die Assertion übertragen wird: SAML definiert mehrere Transport-Bindings. HTTP Redirect komprimiert und base64-kodiert den Request in einen URL-Query-String (begrenzt durch die maximale URL-Länge des Browsers); HTTP POST sendet einen base64-kodierten Blob in einem per JavaScript automatisch abgesendeten Formular (2026 am gebräuchlichsten); HTTP Artifact übergibt einen kurzen Referenztoken, den der SP out-of-band gegen die vollständige Assertion eintauscht. POST ist der moderne Standard, weil es Assertion-Größen bewältigt, die URL-Grenzen mühelos sprengen, und vermeidet, dass die Assertion in Proxy-Logs gelangt. Die Assertion selbst wird in Base64 verpackt und mit SHA-256 signiert.

Operative Fallstricke bei Enterprise-SAML-Rollouts: Uhrzeit-Abweichung (Clock Skew) zwischen IdP und SP (Assertions haben standardmäßig ein Gültigkeitsfenster von 5 Minuten – eine falsch konfigurierte Serverzeit bricht den Login für alle), Zertifikatsrotation (das Signaturzertifikat des IdP läuft alle 1–3 Jahre ab und muss vor diesem Datum rotiert werden, sonst fällt das gesamte SSO gleichzeitig aus) und NameID-Format-Diskrepanzen (der IdP gibt emailAddress aus, aber der SP erwartet persistent opake IDs). Die klassische Enterprise-Anekdote ist ein SSO-Ausfall am Montagmorgen, weil das IdP-Zertifikat in der Sonntagnacht stillschweigend abgelaufen ist und niemand für die Erneuerung verantwortlich war. Referenz: OASIS SAML 2.0 Core specification.

Durchgerechnetes Beispiel

Ein Mitarbeiter klickt auf “Mit Unternehmens-SSO anmelden” auf app.example.com. Der SP (Service Provider) erzeugt ein SAML-<AuthnRequest>-XML-Dokument und sendet es per POST an den IdP unter sso.acme.com/saml. Der IdP authentifiziert den Nutzer (vermutlich per Passwort + WebAuthn) und gibt eine SAML-<Response> zurück, die eine <Assertion> enthält mit: der E-Mail-Adresse des Nutzers (NameID), den Gruppenzugehörigkeiten (AttributeStatement), dem Gültigkeitsfenster (NotBefore / NotOnOrAfter ~5 Minuten) und der Audience-Restriction (muss exakt app.example.com sein). Das XML wird mit dem RSA-2048-Schlüssel des IdP unter Verwendung von SHA-256 signiert. Der Browser sendet diesen base64-kodierten Blob automatisch per POST an app.example.com/saml/acs zurück. Der SP prüft die Signatur gegen das vorab geteilte öffentliche Zertifikat des IdP, kontrolliert Gültigkeitsfenster und Audience, extrahiert die E-Mail-Adresse und erstellt eine lokale Session. Der gesamte Austausch besteht aus zwei HTTP-Weiterleitungen und ist für den Nutzer abgesehen vom Login-Bildschirm des IdP unsichtbar.

Wann und warum es zählt

Wer B2B-SaaS verkauft, für den ist SAML-Unterstützung das entscheidende Feature für Enterprise-Verkäufe – die meisten Unternehmen ab 500 Mitarbeitern schreiben vor, dass jeglicher SaaS-Zugriff über ihren IdP läuft, um die Kontrolle beim Offboarding zu gewährleisten (wenn ein Mitarbeiter geht, widerruft der IdP seine Session, und er verliert den Zugriff auf jedes verbundene SaaS auf einen Schlag). Moderne Sicherheitsvorfälle bei SaaS-Anbietern (Okta 2022, Cloudflare 2023) lassen sich auf die SAML- oder Session-Token-Ebene statt speziell auf Passwörter zurückführen, gerade weil SSO das maßgebliche Credential ist. Die Verteidigungs-Checkliste für jede SAML-Implementierung: prüfen Sie die Signatur jeder Assertion (nicht nur des Response-Wrappers), prüfen Sie InResponseTo, um Replay zu verhindern, prüfen Sie Audience und Recipient, erzwingen Sie das Zeitfenster strikt und speichern Sie den Fingerprint des IdP-Zertifikats out-of-band, damit eine kompromittierte Metadaten-URL den vertrauenswürdigen Schlüssel nicht stillschweigend austauschen kann. Referenz: OWASP SAML Security Cheat Sheet.