Was ist SAML (Security Assertion Markup Language)?

Was ist SAML?

SAML (Security Assertion Markup Language) ist ein XML-basierter offener Standard für den Austausch von Authentifizierungs- und Autorisierungsdaten zwischen einem Identity Provider (IdP) und einem Service Provider (SP). 2005 standardisiert, ist SAML 2.0 das dominante Enterprise-SSO-Protokoll — wenn eine SaaS-App sagt "SSO unterstützt", meinen sie fast immer SAML 2.0. Slack, Salesforce, AWS, Workday, Zoom und tausende andere Enterprise-Anwendungen unterstützen alle SAML.

Der Kern-Mechanismus: Wenn ein Nutzer versucht, sich bei einem Service Provider (deiner App) anzumelden, leitet der SP ihn an den Identity Provider (Okta, Microsoft Entra ID, Google Workspace, Auth0) weiter. Der IdP authentifiziert den Nutzer (verifiziert Passwort, erzwingt MFA), dann gibt er ein digital signiertes XML-Dokument aus, genannt SAML-Assertion. Der Browser des Nutzers trägt diese Assertion zurück zum SP, der die Signatur gegen den öffentlichen Schlüssel des IdP verifiziert und vertraut, dass der Nutzer ist, wer der IdP sagt.

Der SAML-Flow (SP-initiiert, der häufige Fall)

1. Nutzer greift auf den SP zu (z.B. https://app.example.com) und klickt auf "Mit SSO anmelden".
2. SP leitet an IdP weiter mit einem SAML AuthnRequest — einer XML-Nachricht, die sagt "bitte authentifiziere diesen Nutzer für mich". Die Weiterleitung geht durch den Browser des Nutzers via HTTP-Redirect- oder HTTP-POST-Binding.
3. IdP authentifiziert den Nutzer. Username + Passwort, dann MFA, möglicherweise Conditional-Access-Policies. Wenn der Nutzer bereits eine aktive IdP-Session hat, ist dieser Schritt unsichtbar.
4. IdP generiert eine SAML-Response. Ein XML-Dokument, das eine oder mehrere Assertions mit Claims über den Nutzer (Name, E-Mail, Gruppenmitgliedschaften) enthält, digital signiert mit dem privaten Schlüssel des IdP.
5. IdP leitet den Browser des Nutzers zurück zur ACS-URL des SP (Assertion Consumer Service) mit der signierten Response, typischerweise als base64-encoded HTTP-POST-Body.
6. SP validiert die Response. Prüft die Signatur gegen das publizierte öffentliche Zertifikat des IdP, validiert Timestamps (NotBefore/NotOnOrAfter), prüft, ob die Audience seinem erwarteten Entity-ID matched. Wenn alles passt, erstellt der SP eine lokale Session für den Nutzer.

Der Nutzer erlebt das typischerweise als einen einzelnen Browser-Redirect — er klickt auf "Anmelden", sieht kurz die IdP-Seite (oder nicht) und landet bereits authentifiziert wieder in der App. Verstrichene Gesamtzeit: 1-3 Sekunden.

Was in einer SAML-Assertion ist (die XML-Payload)

Eine typische SAML-2.0-Response enthält:

• Issuer: Welcher IdP das signiert hat — wird genutzt, um den richtigen öffentlichen Schlüssel nachzuschlagen.
• Signature: Die XML-Digital-Signatur über die Response (oder die Assertion darin).
• Subject: Identifiziert den Nutzer, typischerweise als NameID (E-Mail, UUID oder transient/persistent Identifier).
• Conditions: NotBefore- und NotOnOrAfter-Timestamps, die binden, wann die Assertion gültig ist (üblicherweise ein 5-Minuten-Fenster).
• AudienceRestriction: Für welchen SP diese Assertion gedacht ist. Wenn die Entity-ID des SP nicht matched, ablehnen.
• AuthnStatement: Wann und wie der Nutzer sich authentifiziert hat (Passwort, MFA etc.).
• AttributeStatement: Custom-Attribute, die der IdP einschließt — E-Mail, Vor-/Nachname, Gruppenmitgliedschaften, Abteilung, Manager, Mitarbeiter-ID. Der SP nutzt diese, um den Nutzer zu provisionieren und zu autorisieren.

Warum SAML verbose ist (und warum es trotzdem persistiert)

SAML ist berühmt-komplex: XML-Namespaces, X.509-Zertifikate, mehrere Signing-/Verschlüsselungs-Optionen, dutzende optionale Felder. Im Vergleich zu JSON Web Tokens (JWT) in OpenID Connect ist eine SAML-Nachricht 10-50× größer in Bytes.

Warum dominiert SAML also weiterhin Enterprise-SSO?

• Network-Effect. Jeder große IdP und jede Enterprise-SaaS unterstützt bereits SAML. Switching-Kosten sind riesig.
• Reifes Tooling. 20 Jahre Libraries, Debugger, Test-IdPs. Beschaffungsteams wissen, wie man SAML-Support evaluiert.
• Enterprise-Gewohnheiten. Käufer verlangen explizit SAML in RFPs. "OIDC-only" ist ein Non-Starter für die meiste große Beschaffung.
• Echte Security-Tiefe. SAML unterstützt komplexe Use Cases (verschlüsselte Assertions, Attribut-Verschlüsselung, Multi-Tier-Signing), die einfachere Protokolle ungeschickt handhaben.

Für neue Integrationen zwischen modernen Systemen ist OpenID Connect (gebaut auf JWT und OAuth 2.0) einfacher und zunehmend bevorzugt. Für Enterprise-SaaS ist SAML weiterhin erforderlich — die meisten Production-Systeme unterstützen beides.

Häufige SAML-Implementierungs-Gotchas

• Clock-Skew. SAML-Assertions haben NotBefore- und NotOnOrAfter-Timestamps. Wenn die Uhren von IdP und SP um mehr als die konfigurierte Toleranz (üblicherweise 60-300 Sekunden) abweichen, schlägt die Authentifizierung fehl. Alles per NTP synchronisieren.
• Zertifikatsrotation. SAML-Signaturen nutzen X.509-Zertifikate, die ablaufen (typischerweise 1-3 Jahre). Vergessen, vor Ablauf zu rotieren, legt SSO um 03:00 Uhr an einem Dienstag lahm. Kalender-Erinnerungen sind Pflicht; Metadata-Exchange (Auto-Rotation) ist in der Praxis selten.
• Gruppen-Claim-Mapping. Der IdP sendet Gruppen in der Assertion; der SP muss diese auf lokale Rollen mappen. Falsch konfigurierte Gruppen-Mappings sind die #1-Quelle für "warum bin ich kein Admin?"-Tickets.
• SP-initiiert vs. IdP-initiiert. Manche SaaS-Apps unterstützen beides; manche nur SP-initiiert. IdP-initiiert (Nutzer startet im Okta-Dashboard, klickt auf SP-Tile) ist praktisch, führt aber Sicherheitsbedenken ein — der SP muss Assertions akzeptieren, die er nicht angefordert hat.
• NameID-Format. Verschiedene IdPs defaulten auf verschiedene NameID-Formate (E-Mail vs. persistent UUID vs. transient). Der SP muss sich einigen, welches zu erwarten ist, sonst bricht das Matching.
• Replay-Protection. SP muss IDs kürzlich-validierter Assertions erinnern und Duplikate ablehnen. Ohne das können abgefangene Assertions replayed werden.

SAML vs. OIDC vs. OAuth 2.0

Die drei oft verwechselten Protokolle:

• SAML 2.0: XML-basierter Authentifizierungs-Standard. Dominant in Enterprise-SSO. Verbose, aber robust.
• OAuth 2.0: Autorisierungs-Framework — "darf diese App auf die Daten dieses Nutzers zugreifen?" Etabliert Identität nicht von selbst.
• OpenID Connect (OIDC): Authentifizierungs-Schicht gebaut auf OAuth 2.0. JSON-basiert, JWT-Tokens. Modern, einfacher als SAML. Treibt "Mit Google/Apple/Microsoft anmelden".

Praktische Anleitung: Implementiere OIDC für Self-Service-/Consumer-Signups (einfacher, JSON-freundlich); füge SAML für Enterprise-Kunden hinzu (verpflichtend für viele Beschaffungsteams).

FAQ: SAML

Ist SAML 2026 noch relevant?

Ja — für Enterprise-SSO ist es weiterhin der dominante Standard. OIDC gewinnt Boden für neue Integrationen und Consumer-Auth, aber SAMLs Enterprise-Install-Base bedeutet, dass es auf absehbare Zeit erforderlich sein wird. Plane, beides zu unterstützen.

Was ist der Unterschied zwischen SAML und OAuth?

Verschiedene Zwecke. SAML ist Authentifizierungs-first ("wer ist dieser Nutzer?"). OAuth ist Autorisierungs-first ("darf diese App auf die Ressourcen dieses Nutzers zugreifen?"). Sie werden oft kombiniert — SAML für SSO, OAuth für API-Zugriff. OIDC merged die beiden, indem es Identitäts-Claims zu OAuth hinzufügt.

Warum nutzt SAML XML, wenn JSON heute überall ist?

Historischer Zufall. SAML 2.0 wurde 2005 finalisiert, bevor JSON das Web dominierte. Als JSON zum Default wurde, war SAMLs Enterprise-Install-Base zu groß zum Migrieren. Neue Protokolle (OIDC) nutzen JSON; SAML bleibt XML aus Kompatibilitätsgründen.

Ist SAML sicher?

Ja, wenn korrekt implementiert. Das Protokoll ist gut spezifiziert und battle-tested. Die meisten SAML-Breaches kommen von Implementierungs-Bugs (Signatur-Validierungs-Flaws, Replay-Attacks) statt Protokoll-Schwächen. Nutze eine battle-tested SAML-Library; baue das XML-Parsing nicht selbst.

Wie debugge ich eine SAML-Integration?

Tools: SAML-Tracer Firefox-Extension (capturet und decodet SAML-Nachrichten), Online-SAML-Decoder (paste base64-encoded Assertions, kriege lesbares XML), IdP-Debug-Logs (Okta, Auth0, Microsoft alle exponieren detaillierte Traces) und SP-Error-Pages mit Verbose-Modus aktiviert. Die meisten SAML-Bruchstücke sind Signatur-Mismatch oder Clock-Skew — die zuerst prüfen.

Was ist SCIM und wie verhält es sich zu SAML?

SCIM (System for Cross-domain Identity Management) automatisiert User-Provisioning zwischen IdP und SPs. SAML handhabt Authentifizierung (Login); SCIM handhabt "erstelle diesen Nutzer, wenn er zum IdP hinzugefügt wird, lösche ihn, wenn er entfernt wird". Zusammen sind SAML + SCIM der Goldstandard für managed Enterprise-SaaS.

Wie LoadFocus zu SAML-SSO steht

LoadFocus unterstützt SAML 2.0 SSO in Enterprise-Plänen (neben OIDC). Für Lasttest von Apps, die SAML-Auth nutzen, unterstützt unser Lasttest OAuth-Flows für Service-to-Service-Tokens — das typische Muster ist, einen Service-Account mit Token-Exchange zu nutzen statt browser-basierter SAML für synthetischen Traffic. API-Monitoring validiert, dass SAML-geschützte Endpoints korrekt antworten, wenn von Automation getriggert.