Was ist SAML (Security Assertion Markup Language)?

Was ist SAML?

SAML (Security Assertion Markup Language) ist ein XML-basierter Standard, um Authentifizierungs- und Attributinformationen über einen Nutzer von einem Identity Provider (IdP) an einen Service Provider (SP) zu übergeben. SAML V2.0 wurde am 15. März 2005 OASIS Standard. Es wird häufig für Single Sign-on (SSO) in Unternehmen eingesetzt: Der Nutzer meldet sich einmal beim IdP an, und der IdP bürgt mit einer signierten Assertion gegenüber jeder Anwendung für ihn.

Die zwei Rollen

• Identity Provider (IdP): authentifiziert den Nutzer und stellt Assertions aus. Hier liegen die Konten, und hier werden Regeln wie MFA durchgesetzt. Das gehört zum größeren Thema Identity and Access Management.
• Service Provider (SP): die Anwendung, die der Nutzer erreichen will. Sie verarbeitet die Assertion und entscheidet über den Zugriff.

So läuft der SAML-Ablauf (SP-initiiert)

1. Der Nutzer öffnet den SP und wählt die Anmeldung per SSO.
2. Der SP leitet den Browser mit einer Authentifizierungsanfrage (AuthnRequest) zum IdP um.
3. Der IdP authentifiziert den Nutzer oder nutzt eine bestehende IdP-Sitzung weiter.
4. Der IdP erstellt eine SAML-Response mit einer signierten Assertion über den Nutzer.
5. Der Browser liefert die Response beim Assertion Consumer Service (ACS) des SP ab, normalerweise per HTTP POST.
6. Der SP prüft Signatur und Bedingungen und legt dann seine eigene lokale Sitzung an.

Beim IdP-initiierten Ablauf startet der Nutzer beim IdP, etwa über ein App-Dashboard, und der IdP sendet eine Assertion ohne AuthnRequest. Die technische Übersicht von OASIS beschreibt beides. Die Nachrichten laufen über Bindings wie HTTP Redirect, HTTP POST und HTTP Artifact.

Was in einer Assertion steckt

Eine Assertion enthält ein Subject, Bedingungen und Aussagen. Üblich sind:

• Issuer und Signatur: wer sie ausgestellt hat, und der Nachweis, dass nichts verändert wurde.
• Subject: über wen die Assertion etwas aussagt, oft als NameID, etwa eine E-Mail-Adresse oder eine undurchsichtige Kennung.
• Conditions: ein Gültigkeitszeitraum (NotBefore und NotOnOrAfter) und eine AudienceRestriction, die den Service Provider benennt, für den die Assertion bestimmt ist.
• Authentication Statement: wie und wann sich der Nutzer authentifiziert hat.
• Attribute Statement: Angaben wie Name, E-Mail oder Gruppenzugehörigkeit, die der SP zur Autorisierung nutzen kann.

Beispiel

Eine Mitarbeiterin öffnet das Projekttool ihrer Firma. Das Tool leitet zum Unternehmens-IdP um, sie bestätigt eine Push-Nachricht, und der IdP sendet eine Assertion mit ihrer E-Mail-Adresse, dem Projekttool als Audience und einem Gültigkeitsfenster von wenigen Minuten zurück. Das Tool prüft die Signatur gegen das hinterlegte IdP-Zertifikat, bestätigt, dass es selbst die Audience ist, prüft das Zeitfenster, ordnet das Gruppenattribut einer Rolle zu und meldet sie an.

Häufige SAML-Fehler

• Zeitabweichung. Weichen die Uhren von IdP und SP stärker ab als die Toleranz, scheitert die Prüfung des Gültigkeitsfensters. Beide per NTP synchron halten.
• Abgelaufene Signaturzertifikate. Läuft das IdP-Zertifikat ab oder wird es getauscht und der SP kennt noch das alte, scheitert jede SSO-Anmeldung sofort. Ablaufdaten im Blick behalten.
• Audience- oder ACS-Abweichung. Entity-ID und ACS-URL beim IdP müssen genau zu dem passen, was der SP erwartet.
• NameID-Format. Sendet der IdP eine Kennung in einem anderen Format, als der SP abgleicht, werden Nutzer nicht gefunden oder doppelt angelegt.
• Gruppenzuordnung. Ein falscher Attributname oder Wert lässt Nutzer ohne ihre Rolle zurück.
• Schwache Signaturprüfung oder kein Replay-Schutz. Nutzen Sie eine gepflegte SAML-Bibliothek, prüfen Sie die Signatur über das richtige Element und weisen Sie bereits verwendete Assertions ab. Die Spezifikation kennt außerdem eine OneTimeUse-Bedingung.

SAML, OAuth 2.0 und OpenID Connect im Vergleich

• SAML 2.0: XML-Nachrichten, gebaut für Browser-SSO zwischen Organisationen und Anwendungen.
• OAuth 2.0: ein Autorisierungs-Framework, mit dem eine App im Namen eines Nutzers auf Ressourcen zugreift. Es ist allein kein Anmeldeprotokoll. Token wie das Bearer-Token sind bei API-Aufrufen üblich.
• OpenID Connect: eine Identitätsschicht auf OAuth 2.0, die JSON und JWTs nutzt.

SAML, APIs und Tests

SAML ist ein Browser-Redirect-Protokoll und schützt daher die Anmeldeseite, nicht API-Aufrufe. APIs hinter einem SSO-geschützten Produkt akzeptieren meist ein Token, und genau das testen Sie: siehe API-Sicherheit und die Anleitung zum OAuth2-Lasttest. Das API-Monitoring von LoadFocus kann die geprüften APIs mit OAuth-Bearer-Token authentifizieren. LoadFocus selbst bietet kein SAML- oder OIDC-Single-Sign-on an: Die Anmeldung bei LoadFocus erfolgt mit E-Mail und Passwort oder mit Google.

Häufige Fragen: SAML

Wofür steht SAML?

Security Assertion Markup Language. Eine Assertion ist eine Aussage über einen Nutzer, die die ausstellende Stelle als wahr behauptet, etwa wer er ist und wie er sich angemeldet hat.

Was ist der Unterschied zwischen SAML und OAuth?

SAML sagt einer Anwendung, wer der Nutzer ist. OAuth 2.0 lässt eine Anwendung im Namen eines Nutzers handeln. Beide lösen unterschiedliche Probleme, und OpenID Connect ergänzt OAuth um die Identität.

Warum nutzt SAML XML?

SAML 2.0 wurde 2005 fertiggestellt, als XML das übliche Format für einen solchen Austausch war. Neuere Protokolle wie OpenID Connect nutzen JSON.

Ist SAML sicher?

Das Protokoll ist gut spezifiziert, die meisten Ausfälle entstehen aber in der Umsetzung: schwache Signaturprüfungen, fehlende Audience- oder Zeitprüfungen und kein Replay-Schutz. Nutzen Sie eine gepflegte Bibliothek und parsen Sie das XML nicht selbst.

Wie debugge ich eine fehlgeschlagene SAML-Anmeldung?

Zeichnen Sie die SAML-Response im Browser auf, dekodieren Sie die Base64-Daten und lesen Sie Issuer, Audience, Gültigkeitsfenster und NameID. Vergleichen Sie diese mit der SP-Konfiguration und prüfen Sie beide Uhren. Signatur, Audience, Uhrzeit und Zertifikat erklären die meisten Fehler.

Unterstützt LoadFocus SAML-Single-Sign-on?

Nein. Die Anmeldung bei LoadFocus erfolgt mit E-Mail und Passwort oder mit Google. LoadFocus kann Anwendungen und APIs hinter SAML testen und überwachen, indem es das Token verwendet, das diese APIs akzeptieren.