SAML-Parser

SAML (Security Assertion Markup Language) ist ein XML-basierter Standard für den Austausch von Authentifizierungs- und Autorisierungsdaten zwischen Identity-Providern (IdPs) und Service-Providern (SPs). Dieses Tool dekodiert SAML-Nachrichten aus URLs, verarbeitet Base64- und DEFLATE-Kodierung und formatiert das XML zur Überprüfung.

Spezifikationen

• OASIS SAML 2.0 Core
• OASIS SAML 2.0 Bindings
• SAML 2.0 Technical Overview

Haeufige Anwendungsfaelle

• Enterprise-Single-Sign-On-Authentifizierungsflows (SSO) debuggen
• SAML-Assertions von Identity-Providern untersuchen (Okta, Azure AD, ADFS)
• SAML-Integration zwischen Diensten beheben
• Assertion-Attribute und NameID-Werte überprüfen
• AuthnContext und Sitzungsparameter analysieren
• SAML-Konfigurationen für Sicherheitsüberprüfungen auditieren

Funktionen

• SAML-AuthnRequest-Nachrichten parsen (SP zu IdP)
• SAML-Response und -Assertions dekodieren (IdP zu SP)
• SAMLRequest und SAMLResponse aus URL-Abfrageparametern extrahieren
• Base64-Kodierung und DEFLATE-Komprimierung verarbeiten (HTTP-Redirect-Binding)
• XML-Struktur mit Syntaxhervorhebung formatiert ausgeben
• Nachrichtenübersicht anzeigen (Typ, ID, IssueInstant, Destination, Status)
• Issuer, Subject/NameID und Conditions extrahieren
• Assertion-Attribute aus dem AttributeStatement anzeigen
• Signatur-Präsenzindikator

Beispiele

https://sp.example.com/acs?SAMLResponse=PHNhbWxwOlJlc3BvbnNlLz4=

Tipps

• SAML verwendet zwei Haupt-Bindings: HTTP-Redirect (GET mit Deflate+Base64) und HTTP-POST (POST mit Base64).
• Der RelayState-Parameter bewahrt die ursprünglich angeforderte URL über den SSO-Flow hinweg.
• SAML-Assertions können signiert, verschlüsselt oder beides sein. Dieses Tool zeigt den dekodierten Inhalt.
• Prüfen Sie die NotBefore- und NotOnOrAfter-Bedingungen, um die zeitliche Gültigkeit der Assertion zu validieren.

Verstaendnis SAML-Parser

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). SAML 2.0, veröffentlicht von OASIS im Jahr 2005, bleibt das dominierende Protokoll für Enterprise Single Sign-On (SSO), das es Mitarbeitern ermöglicht, sich einmal zu authentifizieren und auf mehrere Anwendungen zuzugreifen.

Ein SAML-SSO-Flow funktioniert wie folgt: Ein Benutzer versucht, auf einen Service-Provider zuzugreifen, der SP generiert einen AuthnRequest und leitet den Browser zum IdP um, der IdP authentifiziert den Benutzer und erstellt eine SAML-Response mit Assertions, und der Browser sendet diese Response per POST zurück an den SP. Die Assertion enthält die Identität des Benutzers (NameID), Attribute (E-Mail, Gruppen, Rollen) und Bedingungen (Gültigkeitsfenster, Audience-Beschränkung).

SAML-Nachrichten werden über Bindings transportiert. Das HTTP-Redirect-Binding kodiert XML mittels DEFLATE-Komprimierung und Base64-Kodierung in einem URL-Abfrageparameter. Das HTTP-POST-Binding verwendet nur Base64 und übermittelt die Daten über ein automatisch absendendes Formular. Das Debuggen von SAML erfordert das Dekodieren dieser Schichten, um das zugrundeliegende XML zu inspizieren.

SAML-Assertions können signiert (um zu beweisen, dass sie vom IdP stammen), verschlüsselt (um zu verhindern, dass Zwischeninstanzen den Inhalt lesen) oder beides sein. Bei der Fehlersuche von SSO-Problemen besteht der erste Schritt immer darin, die SAML-Response zu dekodieren und die Bedingungen, Audience, Zeitstempel und Attributwerte der Assertion zu prüfen.

SAML und OAuth 2.0/OpenID Connect dienen unterschiedlichen Zwecken. SAML ist für Enterprise-SSO konzipiert und verwendet XML-basierte Assertions, die über Browser-Redirects transportiert werden, und ist am häufigsten in Unternehmensumgebungen mit Identity-Providern wie ADFS und Okta anzutreffen. OAuth 2.0 ist ein Autorisierungsframework für API-Zugriff mit JSON-Tokens, und OpenID Connect fügt eine Authentifizierungsschicht auf OAuth mit JWTs hinzu. OIDC ist verbreiteter in modernen Web- und Mobilanwendungen, während SAML in der Unternehmens-IT dominant bleibt.

SAML-Nachrichten erscheinen oft als unverständliche Zeichenketten, da sie für den Transport kodiert sind. Beim HTTP-POST-Binding wird das XML Base64-kodiert. Beim HTTP-Redirect-Binding wird das XML zuerst DEFLATE-komprimiert, dann Base64-kodiert und anschließend URL-kodiert. Das Lesen des Original-XML erfordert das Rückgängigmachen dieser Schichten in der richtigen Reihenfolge. Dieses Tool übernimmt automatisch alle Dekodierungsschritte, unabhängig davon, welches Binding verwendet wurde.

Bei der Fehlersuche von SAML-Fehlern sollten mehrere häufige Ursachen geprüft werden: Zeitabweichungen zwischen IdP und SP können dazu führen, dass Assertion-Zeitstempel die Validierung nicht bestehen; das Audience-Element muss exakt mit der konfigurierten Entity-ID des SP übereinstimmen; Assertions können ihre NotOnOrAfter-Zeit überschritten haben; das Destination-Attribut muss mit der Assertion-Consumer-Service-(ACS-)URL des SP übereinstimmen; und der SP hat möglicherweise nicht das aktuelle Signaturzertifikat des IdP, wenn es kürzlich ausgetauscht wurde. Der RelayState-Parameter spielt ebenfalls eine wichtige Rolle im SSO-Flow — er bewahrt die ursprünglich angeforderte URL des Benutzers über die Authentifizierungsumleitung hinweg, sodass der SP nach erfolgreicher Authentifizierung zur Seite zurückleiten kann, die der Benutzer ursprünglich aufrufen wollte.