Security Assertion Markup Language (SAML) 2.0 ist ein XML-basiertes Protokoll, das den Identitätsverbund zwischen separaten Sicherheitsdomains ermöglicht und somit Single Sign-On (SSO) bereitstellt. Dank SAML können sich Benutzende einmalig bei einem Identity-Anbieter (IdP) authentifizieren und anschließend auf mehrere Service Provider zugreifen, ohne ihre Anmeldedaten erneut eingeben zu müssen.

SAML 2.0 wurde im Jahr 2005 als offener OASIS-Standard ratifiziert. Es wird weiterhin häufig für den Identitätsverbund in Unternehmen und Behörden eingesetzt, obwohl OpenID Connect (OIDC) für moderne Anwendungen immer häufiger anzutreffen ist.

Beispiel: Wenn Sie sich beim internen Hub Ihres Unternehmens anmelden, ermöglicht Ihnen SAML den sofortigen Zugriff auf GitHub Enterprise-Repositories, Jira-Tickets und Confluence-Dokumentation – den ganzen Tag über, ohne dass Sie Ihre Anmeldedaten für jedes Tool erneut eingeben müssen. Das Portal fungiert dabei entweder als Service Provider oder als IdP-basierter Anwendungsstarter. Die nachgelagerten Tools (Jira, GitHub Enterprise) sind zusätzliche Service Provider, die demselben Identity-Anbieter vertrauen.

SAML unterstützt zwei Initiierungsmuster, die beide SSO etablieren.

Vom Service Provider initiierter Flow (Standard für B2B-SaaS)

Wenn ein Benutzender versucht, direkt auf die Anwendung zuzugreifen:

1. Der Benutzende versucht, auf die Anwendung zuzugreifen (Service Provider).
2. Die Anwendung leitet den Benutzenden zur Login-Seite des Identity-Anbieters weiter.
3. Der Benutzende authentifiziert sich beim Identity-Anbieter.
4. Der Identity-Anbieter generiert eine signierte SAML-Assertion.
5. Der Identity-Anbieter leitet den Benutzenden mit der Assertion zurück zur Anwendung.
6. Die Anwendung validiert die Assertion-Signatur und erstellt eine Session.
7. Der Benutzende greift auf Ihre Anwendung zu.

Vom Identity-Anbieter-initiierter Flow (üblich in Unternehmensumgebungen)

Wenn ein Benutzender von seinem Unternehmens-Dashboard aus startet:

1. Der Benutzende meldet sich bei seinem Unternehmensportal (Identity-Anbieter) an.
2. Der Benutzende klickt in seinem Dashboard auf die Anwendung.
3. Der Identity-Anbieter generiert eine signierte SAML-Assertion.
4. Der Identity-Anbieter leitet den Benutzenden automatisch mit der Assertion zur Anwendung (Service Provider) weiter.
5. Die Anwendung validiert die Assertion und erstellt eine Session.
6. Der Benutzende greift auf die Anwendung zu.

Beide Verfahren verifizieren die Identität, ohne dass Passwörter zwischen Systemen ausgetauscht werden müssen. Der Identity-Anbieter kann vor der Multi-Faktor-Authentifizierung (MFA) die Assertion verlangen und so eine zusätzliche Sicherheitsebene hinzufügen.

Vom Identity-Anbieter initiiertes SSO enthält keinen InResponseTo-Wert vom Service Provider. Service Provider verlassen sich bei der Validierung von IdP-initiierten Assertions eher auf Assertion-Zeitstempel (NotBefore/NotOnOrAfter) und den Replay-Schutz.

SAML ermöglicht den Identitätsverbund durch drei zentrale Komponenten:

• Identity-Anbieter: System, das Benutzende authentifiziert und Anmeldedaten speichert
• Service Provider: Anwendung, die Authentifizierung und Zugriffsgewährung vom Identity-Anbieter vornehmen lässt
• SAML-Assertion: Digital signiertes XML-Dokument mit verifizierten Identity-Daten, das vom Identity-Anbieter an den Service Provider weitergegeben wird

Die Assertion bestätigt die Identität des Benutzenden und die Zugriffsrechte, für den er autorisiert ist, sodass der Service Provider den Zugriff gewähren oder verweigern kann, ohne die Anmeldedaten des Benutzenden direkt zu verarbeiten.

Eine SAML-Assertion ist ein strukturiertes XML-Dokument mit drei Aussagetypen:

• Authentifizierungsaussagen: Bestätigen, dass der Benutzende authentifiziert ist, und protokollieren den Zeitpunkt des Ereignisses.
• Attributaussagen: Enthalten Benutzerdaten und Claims (E-Mail-Adresse, Name, Gruppen, Rollen). Die meisten Implementierungen übermitteln Autorisierungsdaten (wie Rollen oder Gruppen) über Attributaussagen. In SAML-Implementierungen für Mitarbeitende enthalten Attributaussagen üblicherweise autorisierungsbezogene Daten wie Gruppen oder Rollen.
• Aussagen zur Autorisierungsentscheidung: In der SAML-Spezifikation definiert, aber in heutigen SSO-Implementierungen selten verwendet.

Die Assertion beinhaltet:

• Aussteller: Welcher Identity-Anbieter hat es erstellt?
• Subjekt: Wer ist der Benutzende?
• Bedingungen: Gültigkeitszeitfenster (z. B. NotBefore und NotOnOrAfter) sowie die Zielgruppe
• Signatur: Kryptografischer Echtheitsnachweis. Der Service Provider muss überprüfen, ob es sich bei dem verarbeiteten Element um dasselbe Element handelt, auf das die Signatur-ID verweist, um XML Signature Wrapping-Angriffe zu verhindern.

Die Assertion kann verschlüsselt sein, wobei meist das <Assertion>-Element und nicht die gesamte <Response> verschlüsselt ist, obwohl für sensible Daten auch einzelne Attribute verschlüsselt werden können. Der Service Provider muss bei Bedarf in der Lage sein, verschlüsselte Elemente zu entschlüsseln.

Entwicklungsteams verwechseln SAML oft mit OAuth 2.0 und OIDC. Das sind die Unterschiede:

Aspekt	SAML 2.0	OAuth 2.0	OpenID Connect
Primäre Nutzung	Enterprise SSO-Authentifizierung	Delegierte Autorisierung	Moderne Authentifizierung
Format	XML (komplexe Verarbeitung; Risiko von XML Signature Wrapping-Angriffen)	Laut Spezifikation unabhängig vom Token-Format, obwohl viele Implementierungen JWT-Access Token verwenden	JSON-basiert (JWT-ID-Token)
Token-Typ	SAML Assertion	Zugriffstoken	ID-Token und Access Token
Übertragung	Authentifizierungsanfragen verwenden in der Regel HTTP-Redirect; Assertions werden fast immer per HTTP-POST übermittelt	Meist über den HTTP-Autorisierungs-Header (Bearer Token), obwohl je nach Flow auch andere Transportwege (form_post/query) existieren	HTTP-Autorisierungs-Header
Unterstützung für Mobilgeräte	Schlechte Unterstützung für native Apps (erfordert oft WebView oder eine Broker-App)	Sehr gut	Sehr gut
Zielgruppe	Unternehmen, Behörden	Consumer-Apps, APIs	Consumer-Apps, moderne Unternehmen
Anwendungsfälle	Enterprise SSO, Mitarbeiterauthentifizierung	API-Zugriffsdelegierung, Drittanbieterintegrationen	Moderne Apps, mobile Authentifizierung, SSO für Verbrauchende

OAuth 2.0 übernimmt die Autorisierung (was Sie tun können), aber nicht die Authentifizierung (wer Sie sind). OAuth 2.0 allein ist kein Authentifizierungsprotokoll. Anbieter verwenden oft proprietäre Methoden, um damit Identity-Informationen zu übertragen. Diese Methoden sind jedoch nicht standardisiert. OpenID Connect ist der Standard, um OAuth 2.0 mit Authentifizierung zu erweitern.

SAML übernimmt die Authentifizierung und kann Autorisierungsattribute enthalten, ist aber kein Autorisierungs-Framework. Autorisierungsentscheidungen werden in Ihrer Anwendung getroffen, nachdem die SAML-Authentifizierung abgeschlossen ist.

Die Protokolle schließen sich nicht gegenseitig aus. Viele Identity-Plattformen unterstützen alle drei, sodass Sie je nach den Bedürfnissen Ihrer Benutzenden wählen können.

XML-Signaturvalidierung

SAML setzt aus Sicherheitsgründen auf XML-Signaturen. Die korrekte Implementierung der Validierung ist komplex:

• Signaturalgorithmus validieren (schwache Algorithmen wie SHA-1 ablehnen)
• Kette der Signaturzertifikate überprüfen
• Ablauf und Sperrstatus des Zertifikats überprüfen
• Sicherstellen, dass das signierte Element mit dem analysierten Inhalt übereinstimmt
• Service Provider sollten mindestens eine vertrauenswürdige Signatur validieren (für <Response> oder <Assertion>, abhängig von der Konfiguration) und sicherstellen, dass nur das erwartete Element verarbeitet wird.
• Service Provider müssen sicherstellen, dass die Signatur die korrekte Referenz enthält, um XML-Wrapping zu verhindern. Manche Bibliotheken setzen den Referenzabgleich möglicherweise nicht durch. Überprüfen Sie, ob die Signatur auf die korrekte Element-ID verweist.

Ein einziger Fehler bei der Signaturvalidierung schafft eine Schwachstelle. Angreifer können die Authentifizierung mithilfe von XML-Signatur-Wrapping umgehen.

Es ist sinnvoll, eine getestete SAML-Bibliothek zu verwenden, anstatt eine von Grund auf neu zu erstellen.

Zeitabweichung und Zeitstempelvalidierung

SAML-Assertions beinhalten NotBefore- und NotOnOrAfter-Bedingungen. Uhrzeitunterschiede zwischen Identity-Anbieter und Service Provider können dazu führen, dass gültige Assertions zurückgewiesen werden.

Best Practices:

• Erlauben Sie eine Abweichung der Uhrzeit von 2–5 Minuten.
• Implementieren Sie eine korrekte NTP-Konfiguration auf Ihren Servern.
• Protokollieren Sie Fehler bei der Zeitstempelvalidierung separat für das Debuggen.

Metadatenaustausch

SAML verwendet in der Regel den Metadatenaustausch zwischen Identity-Anbieter und Service Provider, obwohl dies in der Spezifikation nicht zwingend vorgeschrieben ist:

• Identity-Anbieter-Metadaten: Enthalten Signaturzertifikate, Endpoints und Entity-ID
• Service Provider-Metadaten: Definieren für Ihre Anwendung die ACS-URLs (Assertion Consumer Service) und Anforderungen

Änderungen an Metadaten führen zu SSO-Fehlern. Wenn Identity-Anbieter Zertifikate rotieren, müssen Sie die Konfiguration aktualisieren. Einige Unternehmen benötigen eine manuelle Genehmigung für Service Provider-Metadatenänderungen, was die Bereitstellung verzögern kann.

Speichern Sie Identity-Anbieter-Metadaten in Ihrer Datenbank, nicht in Konfigurationsdateien. Nicht alle Identity-Anbieter unterstützen dynamische Metadaten-URLs. Wenn verfügbar, wird die automatische Aktualisierung als Best Practice empfohlen.

Inkonsistenzen bei der Attributzuordnung

Unterschiedliche Identity-Anbieter senden unterschiedliche Attributnamen. Die Anwendung benötigt eine flexible Attributzuordnung, um diese Variationen zu verarbeiten. Lassen Sie die Kundenunternehmen konfigurieren, welche SAML-Attribute den Benutzerfeldern Ihrer Anwendung zugeordnet werden.

Bei Verwendung der rollenbasierten Zugriffskontrolle (RBAC) können Identity-Anbieter Rolleninformationen in SAML-Attributen senden. Die Anwendung muss diese Identity-Anbieter-Rollen mit dem internen Berechtigungssystem abgleichen.

Validieren Sie stets die Signatur

Jede SAML-Assertion muss kryptografisch validiert werden, um Folgendes zu bestätigen:

1. Die Signatur existiert.
2. Die Signatur ist für den Assertion-Inhalt gültig.
3. Die Signaturzertifikatskette führt zu einer vertrauenswürdigen Stammzertifizierungsstelle.
4. Das signierte Element entspricht dem analysierten Inhalt; Service Provider müssen sicherstellen, dass die Signatur die korrekte Referenz enthält, um XML-Wrapping zu verhindern.

Die Validierung von Signaturen sollte niemals vernachlässigt werden, auch nicht in der Entwicklungsphase, da sie unverzichtbar für die SAML-Sicherheit ist.

Validieren Sie alle Assertion-Bedingungen

Neben Signaturen ist Folgendes zu prüfen:

• Issuer: Entspricht dem konfigurierten Identity-Anbieter
• Audience: Enthält die Entity-ID der Anwendung
• NotBefore/NotOnOrAfter: Die aktuelle Zeit liegt im gültigen Zeitfenster
• Recipient: Entspricht Ihrer Assertion-Verbraucherservice-URL (falls vorhanden)
• InResponseTo: Entspricht Ihrer Authentifizierungsanfrage-ID (für vom Service Provider initiierte Flows)

Verhindern Sie Replay-Angriffe und Signatur-Wrapping

Die SAML-Spezifikation schreibt keine einmalige Verwendung von Assertions vor, sodass der Replay-Schutz in der Verantwortung des Service Providers liegt.

1. Speichern Sie die Assertion ID (nicht die Response ID), die wie eine Nonce zur Verhinderung von Replay-Angriffen verwendet wird, in einem Cache, dessen TTL dem Gültigkeitsfenster der Assertion entspricht.
   Best Practice: Legen Sie als Cache-TTL mindestens das NotOnOrAfter-Fenster der Assertion fest, idealerweise mit einem kleinen Puffer (ein paar Sekunden), um die Netzwerklatenz zu berücksichtigen.
2. Lehnen Sie jede Assertion mit einer bereits bekannten ID ab.
3. Löschen Sie abgelaufene IDs regelmäßig, um die Cache-Größe im Rahmen zu halten.

Als erste Maßnahme sollte der Service Provider die Zeitstempel NotBefore und NotOnOrAfter validieren. Das Zwischenspeichern von Assertion-IDs ist zweitrangig.

Verwenden Sie überall HTTPS

SAML-Assertions sollten nur über HTTPS übertragen werden. Obwohl sie signiert sind, setzt die Übertragung über HTTP die Benutzenden einem Risiko für Man-in-the-Middle-Angriffe aus.

Konfigurieren Sie die URL des Assertion Consumer Service (ACS) nur mit HTTPS. Die meisten Identity-Anbieter warnen bei HTTP-Endpoints oder blockieren sie komplett.

Implementieren Sie ordnungsgemäße Logouts

SAML unterstützt Single-Logout (SLO), sodass Benutzende sich von allen verbundenen Anwendungen gleichzeitig abmelden können. Die Implementierung ist optional, wird aber für sicherheitsrelevante Anwendungen empfohlen.

SLO kann Front-Channel (Browser-Weiterleitungen) oder Back-Channel (Server-zu-Server) erfolgen. Front-Channel-SLO wird zwar breit unterstützt, ist aber fehleranfällig. Back-Channel-Logout ist zwar vorhanden, aber komplex und wird selten implementiert. Die Interoperabilität variiert, da verschiedene Identity-Anbieter und Service Provider SLO unterschiedlich implementieren. Rechnen Sie daher damit, mehrere Anbieter testen zu müssen.

Die komplette Neuentwicklung einer sicheren SAML-Implementierung erfordert umfangreiches Fachwissen im Bereich XML-Sicherheit und wird im Allgemeinen nur für Implementierungen von Identity-Anbietern oder für hochspezialisierte Anwendungsfälle empfohlen.

Sie haben folgende Optionen:

Identity-Plattformen

Einige Identity-Plattformen helfen bei der Bewältigung der SAML-Komplexität, indem sie Folgendes bereitstellen:

• Vorkonfigurierte SAML-Identity-Anbieter- und Service Provider-Implementierungen
• Automatische Metadatenverwaltung
• Durchführung der Zertifikatsrotation
• Unterstützung für mehrere Identity-Anbieter pro Anwendung
• Detaillierte Audit-Logs

Dieser Ansatz bietet SAML-Support für große Kundenunternehmen und verwendet gleichzeitig moderne Protokolle (OIDC, OAuth 2.0) für Consumer-Apps. Einige Plattformen übersetzen nahtlos zwischen Protokollen.

SAML-Bibliotheken

Für Teams, die mehr Kontrolle benötigen, übernehmen ausgereifte SAML-Bibliotheken die XML-Analyse, Signaturvalidierung und Protokolldetails auf niedriger Ebene:

• Node.js: passport-saml, samlify
• Python: python3-saml, pysaml2
• Java: Spring Security SAML, OpenSAML
• .NET: Sustainsys.Saml2, ITfoxtec.Identity.Saml2
• Ruby: ruby-saml
• PHP: SimpleSAMLphp

Selbst ausgereifte SAML-Bibliotheken können nicht automatisch auf Replay-Angriffe oder verschlüsselte Assertions reagieren. Entwicklungsteams müssen Caching/Nonces und Entschlüsselung nach Bedarf implementieren und sicherstellen, dass die Signaturreferenz verifiziert wird.

Wählen Sie SAML in folgenden Situationen:

• Kundenunternehmen mit bestehender SAML-Infrastruktur
• Aufbau eines B2B-SaaS, das Enterprise SSO erfordert
• Integration mit Behördensystemen
• RFP-Antworten erfordern SAML-Unterstützung

Wählen Sie OIDC oder OAuth 2.0 in folgenden Fällen:

• Entwicklung von Consumer-Apps
• Authentifizierung für mobile Anwendungen ist erforderlich
• Implementierung der API-Autorisierung
• Einfachere JSON-basierte Protokolle werden bevorzugt
• Komplette Neuentwicklung ohne Legacy-Anforderungen

Viele Anwendungen unterstützen mehrere Protokolle. Der Identity-Anbieter Ihrer Wahl sollte sowohl SAML für Unternehmenskunden als auch OIDC für alle anderen Benutzenden unterstützen. Es kann sinnvoll sein, passwortlose Authentifizierungsmethoden wie WebAuthn und Passkeys zu verwenden, um die User Experience zu verbessern.

Bevor Sie die SAML-Unterstützung offiziell einführen, testen Sie diese gründlich:

Testen Sie mit mehreren Identity-Anbietern

Jeder Identity-Anbieter implementiert SAML geringfügig anders. Gehen Sie nicht davon aus, dass das Verhalten eines Identity-Anbieters auf andere zutrifft. Der Umgang mit Attributnamen, Metadatenformaten und Zertifikaten variiert.

Testen Sie Sonderfälle

• Zeitabweichung (Serverzeit um ±5 Minuten ändern)
• Zertifikatsrotation (Identity-Anbieter-Zertifikate aktualisieren und sicherstellen, dass es keine Ausfallzeiten gibt)
• Ungültige Signaturen (Manipulation von Assertions und Ablehnung bestätigen)
• Abgelaufene Assertions (alte Test-Assertions verwenden)
• Replay-Angriffe (gültige Assertions erneut einreichen und Ablehnung überprüfen)

Erfassen Sie Validierungsfehler

Protokollieren Sie alle SAML-Validierungsfehler mit Assertion ID, Grund, Identity-Anbieter-Entity und Zeitstempel für das Debuggen. Diese Logs sind für das Debuggen von Kundenproblemen unerlässlich. SAML-Ausfälle sind oft eher auf Konfigurationsprobleme als auf Codefehler zurückzuführen.

Welches Problem löst SAML?

SAML bietet SSO über die Bereitstellung des Identitätsverbunds für Unternehmensbenutzer. Der Hauptvorteil besteht in der vereinfachten Anwendungssicherheit, da die Verantwortung für das Speichern und Verwalten von Passwörtern an einen dedizierten Identity-Anbieter übertragen wird. Das verringert die Angriffsfläche der Anwendung, verringert die Zahl der Helpdesk-Anrufe zum Zurücksetzen von Passwörtern und zentralisiert die Durchsetzung von Richtlinien.

Dient SAML zur Authentifizierung oder Autorisierung?

SAML ist in erster Linie ein Authentifizierungs- und Föderationsprotokoll, das zur Überprüfung der Benutzeridentität entwickelt wurde. Es ist an sich kein Autorisierungs-Framework wie OAuth 2.0. SAML beantwortet die Frage: „Wer ist dieser Benutzende?“ durch Übertragung einer signierten Assertion (einer Identitätserklärung) von einem Identity-Anbieter an einen Service Provider. Die Autorisierung bestimmt, was der Benutzende tun kann, und erfolgt nach Abschluss der SAML-Authentifizierung, in der Regel über Benutzerattribute (z. B. Rolle oder Abteilung), die in der SAML-Assertion enthalten sind.

Wie unterscheidet sich SAML von OAuth 2.0 und OpenID Connect?

SAML ist ein älterer, XML-basierter Standard, der für einen unternehmensweiten Identitätsverbund und SSO für Mitarbeitende entwickelt wurde. OAuth 2.0 ist ein Autorisierungs-Framework, das Access Token ausstellt, um delegierten, begrenzten API-Zugriff zu gewähren. OIDC ist eine auf OAuth 2.0 aufbauende Identity-Ebene, die eine standardisierte Authentifizierung über ID-Token (JWTs) hinzufügt und für Web-, Mobil- und API-gesteuerte Anwendungen optimiert ist. Alle drei ermöglichen den Zugriff, aber SAML ist für Enterprise SSO konzipiert, während OAuth und OIDC besser für die heutige Anwendungsauthentifizierung und API-Autorisierung geeignet sind.

Wird SAML immer noch verwendet?

Ja. SAML bleibt ein dominantes Protokoll für Enterprise SSO, insbesondere in großen Unternehmen und Behörden mit vorhandener Identity-Infrastruktur. Während OIDC bei Anwendungen an Bedeutung gewonnen hat, bedeutet die Verbreitung von SAML in Unternehmen, dass es weiterhin aktiv genutzt und unterstützt wird.

Ist SAML sicher? Welche Sicherheitsrisiken bestehen?

Korrekt implementiertes SAML ist sicher. Das Protokoll verwendet digitale XML-Signaturen und Verschlüsselung, um Identity-Daten zu schützen. Risiken können sich aus einer falschen Validierung von Assertions ergeben. Service-Provider müssen XML-Signaturen überprüfen, Assertion-Bedingungen (einschließlich Aussteller, Zielgruppe und Zeitstempel) validieren und einen Replay-Schutz implementieren.

Auth0 hilft Entwicklungsteams, SAML schnell und sicher zu implementieren, sodass Enterprise SSO ohne eine Neuentwicklung oder Wartung der SAML-Infrastruktur erforderlich ist.

In unserer Reihe „Einführung in IAM“ erfahren Sie mehr zum Thema Identity and Access Management.

Mehr erfahren

Diese Materialien dienen nur zur allgemeinen Information. Es liegt in Ihrer Verantwortung, sich mit Blick auf Sicherheit, Datenschutz, Compliance oder geschäftliche Angelegenheiten beraten zu lassen und sich nicht ausschließlich auf die hierin bereitgestellten Informationen zu verlassen.