Security Assertion Markup Language

Security Assertion Markup Language (SAML) ist ein offener, XML-basierter Standard für den Austausch von Authentifizierungs- und Autorisierungsinformationen zwischen zwei Parteien — einem Identity Provider (IdP), der die Identität eines Nutzers verwaltet, und einem Service Provider (SP), der eine Anwendung bereitstellt. Die aktuell relevante Version SAML 2.0 wurde 2005 von OASIS verabschiedet und ist bis heute das dominierende Protokoll für unternehmensweites Web-Single-Sign-On, insbesondere für die Anbindung von SaaS-Anwendungen an interne Verzeichnisdienste wie Active Directory oder Microsoft Entra ID.

Das IdP / SP / Assertion-Modell

Im Zentrum von SAML steht ein klares Rollenmodell. Der Identity Provider authentifiziert den Nutzer — typischerweise gegen ein Unternehmensverzeichnis — und stellt anschließend eine signierte Aussage über dessen Identität aus. Diese Aussage heißt Assertion und ist ein XML-Dokument, das mindestens drei Arten von Statements enthalten kann: Authentication Statements (wann und wie wurde der Nutzer authentifiziert), Attribute Statements (Name, E-Mail, Gruppenzugehörigkeiten, Rollen) und Authorization Decision Statements (welche Ressourcen darf der Nutzer nutzen — in der Praxis selten verwendet). Der Service Provider vertraut der Assertion, weil sie kryptografisch mit dem privaten Schlüssel des IdP signiert ist und das öffentliche Zertifikat des IdP bei der Föderation einmalig hinterlegt wurde.

Typischer Ablauf: SP-initiiertes und IdP-initiiertes SSO

In der Praxis dominieren zwei Flow-Varianten. Beim SP-initiierten SSO ruft der Nutzer zunächst eine Anwendung auf — etwa Salesforce oder ServiceNow. Der SP erkennt, dass keine gültige Session besteht, und leitet den Browser per HTTP-Redirect zum IdP weiter, eingebettet in einen SAMLRequest. Der IdP authentifiziert den Nutzer (Passwort plus MFA, häufig kombiniert mit Conditional Access), erzeugt eine signierte Assertion und sendet sie per HTTP-POST über den Browser zurück an die Assertion Consumer Service URL des SP. Beim IdP-initiierten SSO startet der Nutzer dagegen direkt im Portal des IdP — etwa im "My Apps"-Portal von Entra ID — und wählt eine Anwendung. Der IdP erzeugt unaufgefordert eine Assertion und postet sie an den SP. Diese Variante ist bequem, gilt aber als unsicherer, weil sie keine RelayState-Bindung an einen ursprünglichen Request hat und damit anfälliger für Replay- und CSRF-ähnliche Angriffe ist.

Enterprise-Kontext: Föderation in die Cloud

SAML hat seinen festen Platz dort, wo SaaS-Anwendungen an das interne Identitätssilo angebunden werden müssen. Lange Zeit war ADFS der Standardweg, um Active Directory als IdP für Cloud-Dienste nutzbar zu machen. Heute übernimmt zunehmend Microsoft Entra ID diese Rolle — entweder als alleiniger Cloud-IdP oder als Föderationspartner für hybride Szenarien. SAML-Föderation hat den Vorteil, dass Passwörter das Unternehmen nicht verlassen: Der SaaS-Anbieter sieht nur signierte Assertions, nie die Anmeldedaten selbst. Provisionierung von Konten erfolgt parallel meist über SCIM, weil SAML selbst kein Lifecycle-Management vorsieht. Wir finden in Assessments regelmäßig, dass Unternehmen Dutzende SaaS-Anwendungen über SAML angebunden haben, aber kein zentrales Inventar darüber führen, welcher Dienst welche Attribute erhält und wer die signierenden Zertifikate erneuert.

Bekannte Angriffe auf SAML

Die XML-Natur von SAML hat eine eigene Klasse von Schwachstellen hervorgebracht. XML Signature Wrapping (XSW) nutzt aus, dass viele SAML-Parser die Signatur über einen Teil des Dokuments prüfen, aber einen anderen Teil zur Auswertung heranziehen. Ein Angreifer kann eine legitim signierte Assertion abfangen, das ursprüngliche Element in einen unsignierten Bereich verschieben und ein gefälschtes Element mit denselben Attributen, aber anderem Benutzernamen einfügen. Implementierungen, die nicht streng prüfen, welches Element tatsächlich signiert wurde, akzeptieren die Manipulation. Korrekt umgesetzte Parser verlangen, dass das signierte Element genau das ausgewertete Element ist.

Deutlich schwerwiegender ist Golden SAML. Hier benötigt der Angreifer nicht etwa eine Schwachstelle im Protokoll, sondern Zugriff auf den privaten Token-Signing-Schlüssel des IdP — etwa durch Kompromittierung eines ADFS-Servers oder durch Auslesen des Zertifikatspeichers eines Entra-Connect-Servers. Mit diesem Schlüssel kann er beliebige Assertions für beliebige Nutzer und beliebige Service Provider fälschen, ohne dass der echte IdP jemals involviert ist. Der Angriff hinterlässt keine Spuren in den IdP-Logs, weil die Authentifizierung dort nie stattgefunden hat. Bekannt wurde Golden SAML durch die SolarWinds-Kompromittierung 2020. Schutz bietet nur, den Signing-Key konsequent in ein HSM auszulagern, regelmäßig zu rotieren und den IdP-Server selbst nach Tier-0-Standards zu härten — Stichwort Enterprise Access Model.

SAML im Vergleich zu OAuth und OIDC

SAML und OAuth / OIDC sind keine direkten Konkurrenten — sie lösen ähnliche, aber unterschiedlich akzentuierte Probleme.

In modernen Architekturen findet man häufig beide Protokolle parallel: SAML für die Anbindung etablierter SaaS-Anwendungen, OIDC für eigene APIs, mobile Apps und moderne SPA-Frontends. Microsoft Entra ID, Okta und vergleichbare Plattformen sprechen alle drei Protokolle gleichzeitig — die Wahl ist meist vom Service Provider vorgegeben, nicht vom IdP.

Relevanz für KMUs

Auch in mittelständischen Unternehmen ist SAML längst nicht nur ein Konzern-Thema. Sobald ein Unternehmen mehr als eine Handvoll Cloud-Anwendungen produktiv nutzt, lohnt sich die Föderation über einen zentralen IdP — sei es Entra ID, Google Workspace oder eine Open-Source-Lösung wie Keycloak. Wir finden in Assessments regelmäßig, dass SaaS-Anwendungen jahrelang mit lokalen Passwörtern betrieben werden, obwohl der Anbieter SAML-SSO im Business-Plan bereitstellt — das sogenannte "SSO Tax"-Problem ist ärgerlich, aber die Sicherheitsgewinne (zentrale MFA-Durchsetzung, sofortiger Account-Entzug beim Austritt, einheitliches Audit-Log) überwiegen fast immer. Wer SAML einsetzt, sollte zwei Hausaufgaben fest einplanen: Zertifikatsrotation der Token-Signing-Keys vor Ablauf — abgelaufene Zertifikate sind eine der häufigsten Ursachen für überraschende SSO-Ausfälle — und die kompromisslose Härtung des IdP-Servers, der mit dem Verlust seines privaten Schlüssels die Identität des gesamten Unternehmens verliert.