SAML-Decoder für Response und Request

So dekodieren Sie eine SAML-Nachricht

1. Fügen Sie ein, was Sie haben. All das funktioniert:
   • der reine Wert SAMLResponse oder SAMLRequest, URL-kodiert oder nicht
   • SAMLRequest=… mit oder ohne RelayState, SigAlg und Signature
   • eine ganze Redirect-URL, aus der Adresszeile kopiert
   • das HTML-Formular mit automatischem Absenden und dem versteckten Feld SAMLResponse
   • rohes XML
2. Der Decoder erkennt das Binding: reines Base64 bedeutet HTTP-POST, Deflate-Daten bedeuten HTTP-Redirect.
3. Lesen Sie zuerst die Zusammenfassung, dann das formatierte XML darunter. Das XML wird als Text angezeigt und nie gerendert.

Die Richtung Kodieren macht das Umgekehrte: Fügen Sie einen AuthnRequest ein und erhalten Sie einen Redirect-Wert, einen Parameter SAMLRequest= oder eine ganze URL, gebaut aus dem Attribut Destination. Das ist praktisch, um beim Testen eines Service Providers einen Request erneut abzuspielen.

Redirect-Binding und POST-Binding

Redirect verwendet Kompression, weil URLs in der Praxis Längengrenzen haben. Im Beispiel auf dieser Seite schrumpft ein AuthnRequest mit 464 Zeichen per Deflate auf 273 Bytes und reist als 364 Base64-Zeichen. Responses tragen Signaturen und Zertifikate, sind also zu groß für eine URL und gehen per POST. Der Decoder akzeptiert auch zlib-verpackte Daten, die manche Service Provider beim Redirect statt Raw Deflate senden.

Was Sie prüfen sollten, wenn SSO fehlschlägt

Die Zusammenfassung zieht die Felder heraus, die die meisten Anmeldefehler verursachen:

• Status: alles außer urn:oasis:names:tc:SAML:2.0:status:Success. Ein Untercode wie AuthnFailed, InvalidNameIDPolicy oder RequestDenied nennt den Grund, und StatusMessage liefert oft weitere Details.
• Destination und ACS-URL: müssen exakt mit dem Endpunkt übereinstimmen, der beim Service Provider konfiguriert ist, einschließlich https und abschließendem Schrägstrich.
• Audience: muss der Entity-ID des SP entsprechen. Eine Abweichung ist hier ein häufiger Konfigurationsfehler, nachdem eine Anwendung umbenannt wurde.
• Conditions: NotBefore und NotOnOrAfter werden gegen Ihre Uhr geprüft. „Abgelaufen“ oder „noch nicht gültig“ bei einer frischen Anmeldung deutet auf eine Zeitabweichung zwischen IdP und SP hin.
• InResponseTo: sollte der ID des AuthnRequest entsprechen. Eine Abweichung spricht für eine veraltete oder wiederholt eingespielte Response. Bei IdP-initiierten Anmeldungen fehlt das Attribut, was manche Service Provider ablehnen.
• NameID und Format: die Kennung, die der SP mit seinen Benutzern abgleicht, zum Beispiel emailAddress gegenüber persistent.
• Attribute: jedes Attribut mit allen Werten, um zu bestätigen, dass der IdP die Gruppen oder die E-Mail-Adresse sendet, die der SP zuordnet.

SAML in Python dekodieren

import base64, zlib
from urllib.parse import unquote

def decode_post(value):
    return base64.b64decode(value).decode()

def decode_redirect(value):
    raw = base64.b64decode(unquote(value))
    return zlib.decompress(raw, -15).decode()

Die -15 sagt zlib, dass Raw Deflate ohne Header zu erwarten ist. Rufen Sie unquote nur für Werte auf, die Sie aus einer URL kopiert haben; ein Wert aus einem POST-Formular ist bereits reines Base64, und URL-Dekodierung kann darin + in ein Leerzeichen verwandeln. Mehr dazu unter Base64 in Python; die Kompression erklärt die Seite zu Raw Deflate und zlib.

Datenschutz bei SAML-Assertions

Eine Assertion enthält Namen, E-Mail-Adressen, Gruppenmitgliedschaften und manchmal weitere personenbezogene Daten, und eine gültige, nicht abgelaufene Assertion kann als Anmelde-Token dienen. Diese Seite dekodiert sie lokal und kann sie nirgendwohin senden. Schwärzen Sie Assertions trotzdem, bevor Sie sie in Tickets oder Chats einfügen, und behandeln Sie eine mitgeschnittene Response wie ein Session-Cookie, bis ihr NotOnOrAfter verstrichen ist.

Häufige Fragen