IT-Sicherheit
SAML
SAML 2.0 ist ein XML-Framework für Single Sign-on und Identitätsföderation: Ein Identity Provider stellt signierte Assertions aus, die ein Service Provider prüft.
- XML-basiertes SSO-Framework
- OASIS-Standard (2005)
- Signierte Assertions (XML-DSig)
- IdP und SP, Metadata-Vertrauen
- Enterprise-/Web-SSO
SAML 2.0 (Security Assertion Markup Language) ist seit 2005 der etablierte OASIS-Standard für Single Sign-on und Identitätsföderation im Web. Statt für jede Anwendung eigene Zugangsdaten meldet sich der Nutzer einmal bei einem Identity Provider an, der den anderen Anwendungen eine signierte Aussage über die Identität schickt.
Dieser Artikel erklärt die Rollen von Identity und Service Provider, die signierten Assertions, die Bindings und das Web-Browser-SSO-Profil, den Metadaten-Austausch als Vertrauensanker, die typischen Sicherheitsfragen wie XML-Signature-Wrapping und das fragile Single Logout.
1. Zwei Rollen, eine Vertrauensbeziehung
SAML kennt zwei Hauptrollen: Der Identity Provider (IdP) authentifiziert den Nutzer und stellt signierte Aussagen aus. Der Service Provider (SP) ist die Anwendung, die diese Aussagen prüft und auf ihrer Basis Zugriff gewährt. Zwischen beiden besteht eine vorab eingerichtete Vertrauensbeziehung (Föderation), begründet durch ausgetauschte Metadaten und Zertifikate.
2. Die Assertion
Das übertragene Artefakt ist die Assertion, ein vom IdP mit XML-Signatur signiertes XML-Dokument. Sie kann drei Arten von Aussagen enthalten: ein Authentication Statement (wie und wann angemeldet wurde), ein Attribute Statement (Attribute wie Rolle oder Abteilung) und seltener ein Authorization Decision Statement. Ein Conditions-Element begrenzt die Gültigkeit zeitlich (NotBefore, NotOnOrAfter) und auf die vorgesehene Zielgruppe (AudienceRestriction).
3. Bindings und das Web-SSO-Profil
Wie die Nachrichten transportiert werden, regeln die Bindings; am häufigsten ist die Kombination aus HTTP-Redirect (für die Anfrage des SP an den IdP) und HTTP-POST (für die Assertion-Antwort des IdP an den SP). Im verbreiteten Web-Browser-SSO-Profil wird zwischen SP-initiiertem SSO (Nutzer ruft die Anwendung auf, wird zum IdP geschickt) und IdP-initiiertem SSO unterschieden; letzteres gilt als sicherheitskritischer, weil der schützende Bezug zur ursprünglichen Anfrage fehlt.
4. Metadaten als Vertrauensanker
Das gesamte Vertrauen einer SAML-Föderation hängt an den ausgetauschten Metadaten: Sie enthalten die eindeutige Entity-ID, die öffentlichen Zertifikate für Signatur und Verschlüsselung sowie die Endpunkt-Adressen. Werden Metadaten unsicher bezogen (ohne TLS, ohne Prüfung), ist die ganze Signaturkette wertlos. Die Zertifikatsrotation muss mit allen Partnern koordiniert werden, üblicherweise mit einer Übergangsphase, in der beide Zertifikate gültig sind.
SAML steht und fällt mit der Integrität der Metadaten. Wer Zertifikate und Entity-IDs ungeprüft übernimmt, untergräbt die gesamte Vertrauensbeziehung.
5. Sicherheit: Signaturpflicht und XSW
Zwei Punkte sind sicherheitsentscheidend. Erstens: Eine Assertion ohne gültige IdP-Signatur darf der SP niemals akzeptieren. Zweitens das XML-Signature-Wrapping (XSW): Dabei schmuggelt ein Angreifer ein gefälschtes Element ein, während die Signatur formal noch auf das ursprüngliche Element zeigt, sodass Prüfmodul und Anwendungslogik unterschiedliche Elemente betrachten. Die Schwachstelle liegt nicht im Standard, sondern in fehlerhaften Implementierungen; jede SAML-Bibliothek muss explizit gegen XSW gehärtet sein.
6. Single Logout
SAML definiert auch ein Single Logout (SLO), das den Nutzer bei allen beteiligten Anwendungen abmeldet. In der Praxis gilt es als notorisch fragil: Unterstützt nur ein beteiligter Service Provider das Verfahren nicht oder ist kurz nicht erreichbar, bricht die Abmeldekette ab. SLO ist daher mit realistischen Erwartungen zu planen.
7. Stärken und Grenzen
| Stärken | Grenzen |
|---|---|
| Reifer, stabiler Standard mit breiter Enterprise-Basis | XML ist verbose, Tokens deutlich größer als bei OIDC |
| Reichhaltige, erweiterbare Attribute in Assertions | Implementierung anspruchsvoll (XML-Signatur, XSW-Schutz) |
| Definierter Metadaten-Austausch erleichtert Föderation | Single Logout in der Praxis fragil |
| Gut für browserbasierte Enterprise-Anwendungen | schlecht für native Mobile- und reine API-Szenarien |
| Holder-of-Key-Profil für starke Assertion-Bindung verfügbar | Zertifikatsrotation muss mit allen Partnern koordiniert werden |
Häufige Fragen zu SAML
SAML ist im klassischen Enterprise- und Browser-SSO weit verbreitet und oft alternativlos, wenn Partneranwendungen nur SAML unterstützen. OpenID Connect ist schlanker (JSON statt XML) und besser für native Mobile-Apps und API-Szenarien geeignet und daher für neue Anwendungen meist die erste Wahl. Beide lösen Single Sign-on, unterscheiden sich aber in Format und Einsatzschwerpunkt; viele Identity Provider sprechen beide.
Beim XML-Signature-Wrapping schleust ein Angreifer ein gefälschtes Assertion-Element in die Nachricht ein, während die XML-Signatur formal noch auf das ursprüngliche, gültige Element verweist. Wenn das Signaturprüfmodul ein anderes Element betrachtet als die Anwendungslogik, akzeptiert die Anwendung die gefälschten Daten. Schutz bietet nur eine sorgfältig gehärtete SAML-Bibliothek, die genau das tatsächlich verarbeitete Element gegen die Signatur prüft.
Auch der Autor ist nur ein Mensch, dem Fehler unterlaufen können. Wenn in diesem Beitrag etwas nicht stimmt oder unklar ist, freuen wir uns über einen kurzen Hinweis über das Kontaktformular unten, wir prüfen und korrigieren das.
Der nächste Schritt
SAML im eigenen Haus richtig einsetzen?
Wir klären, ob und wie der Baustein zu Ihrer Infrastruktur passt, und sagen offen, wann sich der Aufwand lohnt und wann nicht.