Die SAML (Security Assertion Markup Language) ist ein XML-basiertes Protokoll für föderierte Authentifizierung. Sie erlaubt einem zentralen Identity Provider (IdP), Identitätsaussagen über einen Nutzer auszustellen, die anschließend von mehreren Service Providern (SP) akzeptiert werden — ohne dass der Nutzer sich bei jedem Dienst einzeln anmelden muss.

SAML ist seit Mitte der 2000er etabliert und vor allem im Unternehmens- und Verwaltungsumfeld weit verbreitet. Im Web-API- und Consumer-Bereich wurde es zunehmend von OpenID Connect abgelöst, behält aber dort seine Stärke, wo Browser-basiertes Single Sign-On in größeren Organisationen gebraucht wird.

Beteiligte Rollen

SAML kennt drei Rollen:

  • Identity Provider (IdP) — verwaltet Identitäten und stellt Aussagen aus.
  • Service Provider (SP) — die Anwendung, die einen authentifizierten Nutzer benötigt.
  • Subject — der Nutzer, über den eine Aussage getroffen wird.

Assertions

Das zentrale Datenobjekt ist die SAML-Assertion — ein signiertes XML-Dokument, das Aussagen über das Subjekt enthält. Drei Typen sind üblich:

  • Authentication Statement — wann und wie der Nutzer sich authentifiziert hat.
  • Attribute Statement — Eigenschaften des Nutzers (Name, E-Mail, Gruppen, Rollen).
  • Authorization Decision Statement — Aussagen über erlaubte Aktionen (in der Praxis selten genutzt).

Typischer Ablauf

Der häufigste Ablauf ist der Web Browser SSO Profile mit SP-initiated Login:

  1. Der Nutzer ruft den Service Provider auf.
  2. Der SP leitet den Browser an den IdP weiter, mit einem AuthnRequest.
  3. Der IdP authentifiziert den Nutzer (z. B. per Passwort, MFA).
  4. Der IdP liefert eine signierte SAML-Response über den Browser zurück an den SP.
  5. Der SP prüft Signatur, Aussteller, Empfänger und Gültigkeit und etabliert eine Sitzung.

Daneben existiert IdP-initiated Login — der Nutzer startet beim IdP und wählt die gewünschte Anwendung aus einem Portal aus.

Bindings

SAML ist transportneutral; konkrete Übertragungswege werden als Bindings bezeichnet:

  • HTTP-Redirect — kompakte AuthnRequests werden im Query-String mitgeschickt.
  • HTTP-POST — Assertions werden als Formular über den Browser zurückgereicht; Standard für die SAML-Response.
  • HTTP-Artifact — der Browser bekommt nur ein Artifact-Token, das der SP über einen direkten Backend-Call beim IdP gegen die Assertion eintauscht.

Abgrenzung zu OAuth 2.0 und OIDC

Die drei Protokolle adressieren ähnliche, aber unterschiedliche Probleme:

  • SAML — föderierte Browser-Authentifizierung, XML, sehr verbreitet im Enterprise-Umfeld.
  • OAuth 2.0 — Autorisierung von API-Zugriffen über Tokens.
  • OpenID Connect — Authentifizierung als Schicht über OAuth 2.0, JSON statt XML.

In modernen Architekturen treffen alle drei nebeneinander auf — SAML für Mitarbeiter-Logins ins Unternehmensportal, OIDC für Kundenanmeldungen, OAuth 2.0 für API-Zugriffe.

/ Weiter

Zurück zu IT

Zur Übersicht