SAML erklärt: Single Sign-on für Firmen und Hochschulen

SAML 2.0 ist ein Standard, mit dem das Anmeldesystem einer Organisation, der Identity Provider, anderen Diensten, den Service Providern, mitteilt, wer ein Nutzer ist und welche Merkmale er hat. Der Nutzer meldet sich einmal beim Identity Provider an, und jeder verbundene Dienst akzeptiert das signierte Ergebnis. Diese Technik steckt hinter vielen Single-Sign-on-Portalen von Firmen und Hochschulen.

Wofür es SAML gibt

Große Organisationen betreiben Dutzende Anwendungen: Personal, Mail, Reisekosten, Lernplattformen. Jeder eigene Konten zu geben, vervielfacht Passwörter und macht es schwer, ausscheidende Beschäftigte überall zu entfernen. Mit SAML liegen die Konten in einem Verzeichnis, und jede Anwendung vertraut einer signierten Assertion daraus. Diese Idee beschreiben allgemeiner Single Sign-on und Identitätsföderation.

SAML 2.0 wurde im März 2005 vom Standardisierungsgremium OASIS verabschiedet (die Spezifikationen liegen auf docs.oasis-open.org). Es ist älter als Smartphones und OAuth, daher die Wahl von XML und browserbasierten Nachrichten.

Die Rollen

Rolle	Aufgabe	Beispiel
Nutzer (Principal)	Möchte eine Anwendung öffnen	Eine Mitarbeiterin
Identity Provider (IdP)	Authentifiziert den Nutzer und stellt Assertions aus	Login des Firmenverzeichnisses, Hochschul-Login
Service Provider (SP)	Die Anwendung, die der Assertion vertraut	Reisekosten-Tool, Bibliotheksdatenbank
Metadaten	XML-Dateien mit Endpunkten und Zertifikaten	Werden beim Verbinden einmal ausgetauscht

So läuft ein SAML-Login ab

Die häufigste Variante ist der vom Service Provider gestartete Login über den Browser.

1. Der Nutzer öffnet die Anwendung (den Service Provider).
2. Die Anwendung erzeugt eine Authentifizierungsanfrage und leitet den Browser zum Identity Provider weiter.
3. Der Identity Provider authentifiziert den Nutzer, etwa mit Passwort und zweitem Faktor oder einem Passkey.
4. Der Identity Provider baut eine signierte XML-Assertion mit Kennung des Nutzers, Anmeldezeit und ausgewählten Merkmalen.
5. Der Browser schickt die Assertion per POST an den Endpunkt des Service Providers (Assertion Consumer Service).
6. Der Service Provider prüft die Signatur mit dem Zertifikat aus den Metadaten des Identity Providers, kontrolliert die Bedingungen und meldet den Nutzer an.

Eine stark gekürzte Assertion sieht so aus:

<saml:Assertion>
  <saml:Issuer>https://idp.example.edu</saml:Issuer>
  <saml:Subject><saml:NameID>user-4711</saml:NameID></saml:Subject>
  <saml:Conditions NotOnOrAfter="2026-10-06T09:19:00Z">
    <saml:AudienceRestriction>
      <saml:Audience>https://library.example</saml:Audience>
    </saml:AudienceRestriction>
  </saml:Conditions>
  <ds:Signature>...</ds:Signature>
</saml:Assertion>

Der Login kann auch beim Identity Provider beginnen (ein Portal mit Kacheln). Diese Variante ist angriffsanfälliger und wird oft nicht empfohlen.

Beispiele aus dem Alltag

• Eine Mitarbeiterin öffnet aus dem Firmenportal die Gehalts- oder Reisekosten-App ohne zweite Anmeldung.
• Eine Studentin gelangt mit dem Hochschulkonto zur Zeitschriftendatenbank eines Verlags, über eine Bildungsföderation, die viele Hochschulen verbindet. Nationale Föderationen und der internationale Dienst eduGAIN setzen stark auf SAML.
• Ein Verwaltungsportal lässt Beschäftigte verschiedener Behörden sich mit dem eigenen Behördenkonto anmelden.
• Grenzüberschreitende eID in der EU: Das eIDAS-Interoperabilitätsrahmenwerk nutzt zwischen den nationalen Knoten ein SAML-basiertes Nachrichtenprofil (siehe Die eigene eID im EU-Ausland nutzen).

Sicherheitsaspekte

• Signatur sauber prüfen. Historisch haben viele Angriffe („XML Signature Wrapping“) Anwendungen dazu gebracht, unsignierten Nachrichtenteilen zu vertrauen. Nutzen Sie gepflegte Bibliotheken und testen Sie mit eingeschalteter Signaturprüfung.
• Bedingungen kontrollieren. Zielgruppe (Audience), Gültigkeitsfenster (NotOnOrAfter), Empfänger und InResponseTo müssen passen, sonst lassen sich Assertions wiederverwenden oder an den falschen Dienst schicken.
• Vom Service Provider gestarteten Login bevorzugen und bei sensiblen Merkmalen signierte oder verschlüsselte Assertions verlangen.
• Den Identity Provider schützen. Ein kompromittierter IdP öffnet jede verbundene Anwendung. Phishing-resistente Anmeldung und enge Überwachung sind Pflicht.
• Minimale Merkmale freigeben. Nur senden, was die Anwendung braucht.
• Zertifikate rechtzeitig erneuern. Abweichende Metadaten sind die häufigste Ursache plötzlicher Login-Ausfälle.

SAML oder OpenID Connect: die Wahl

Wählen Sie SAML, wenn Sie Unternehmenssoftware oder eine Bildungsföderation anbinden, die es bereits anbietet, oder wenn die IT eines Kunden es erwartet. Wählen Sie OpenID Connect für neue Web- und Mobil-Apps und alles, was auch API-Zugriff braucht, weil die Bibliotheken einfacher und die JSON-Token leichter zu untersuchen sind. Wer ein Produkt an Organisationen verkauft, unterstützt häufig beides. In jedem Fall gelten dieselben Grundlagen: starke Anmeldung beim Identity Provider, genaue Prüfung dessen, was ankommt, und möglichst wenige Merkmale.

Für Anwender ist der Unterschied meist unsichtbar: Sie sehen ein Anmeldefenster Ihrer Hochschule oder Firma, und im Hintergrund läuft SAML oder OIDC. Nützlich ist es trotzdem zu wissen, dass die Adresse des Anmeldefensters stimmen muss. Geben Sie Ihr Passwort nur dort ein, wo die Adresse Ihres Arbeitgebers oder Ihrer Hochschule steht, und folgen Sie bei Zweifeln nicht einem Link aus einer unerwarteten Mail.

Status und Versionen

SAML 2.0 ist seit 2005 stabil, ergänzt um spätere Profile und Korrekturen. Identitätsprodukte liefern SAML-Unterstützung als Grundfunktion. Für neue Web- und Mobilprojekte ist OpenID Connect die übliche Wahl; wie es zu seinem OAuth-Fundament steht, erklärt OpenID vs. OAuth.

Verhältnis zu anderen Standards

SAML und OpenID Connect lösen dasselbe Problem mit unterschiedlichen Mitteln. SAML bietet reichere Unternehmensfunktionen und eine lange Praxis, OIDC ist leichter und passt gut zu APIs. Viele Identitätsplattformen sprechen beides und übersetzen dazwischen. SAML ist kein Nachweisformat für Wallets und spielt in OpenID4VP und OpenID4VCI keine direkte Rolle.

Rolle in der EUDI-Wallet

SAML ist vor allem für den Übergang relevant. Heute läuft der grenzüberschreitende Login nach der eIDAS-Verordnung über nationale eID-Knoten, die SAML-Nachrichten austauschen. Die EUDI-Wallet folgt einem anderen Modell: Die Nutzerin hält Nachweise selbst und zeigt sie direkt per OpenID4VP vor. Dienste werden wohl noch eine Weile beides unterstützen, daher bleibt SAML-Wissen für alle nützlich, die Verwaltungssysteme anbinden. Wer aus Deutschland, Österreich oder der Schweiz kommt, begegnet SAML vor allem im Hochschul- und Behördenumfeld.