SAML und Federation

SAML (Security Assertion Markup Language) ist ein XML-basierter Standard zum Austausch von Authentifizierungs- und Autorisierungsdaten, der im Bereich Enterprise-SSO vorherrschend ist.

• Damit kann ein unternehmensweiter Identity Provider gegenüber vielen Anwendungen die Identität eines Benutzers bestätigen.
• SAML 2.0 ist älter als OIDC und in B2B- und Workforce-Identity-Umgebungen weiterhin fest etabliert.

Das Verständnis von SAML ist für den Schutz der Unternehmensföderation unverzichtbar, denn ein einziger Vertrauensfehler kann jede verbundene App offenlegen.

Eine SAML-Föderation hat zwei zentrale Parteien.

• Identity Provider (IdP) authentifiziert den Benutzer und stellt Assertions aus (Okta, Entra ID, Ping).
• Service Provider (SP) ist die Anwendung, die dem IdP vertraut und Zugriff gewährt.

Das Vertrauen wird außerhalb des Protokolls durch den Austausch von Metadaten hergestellt, darunter Signaturzertifikate und Endpunkt-URLs.

Das zentrale Artefakt ist die Assertion, ein XML-Dokument, das besagt, dass der IdP ein Subjekt authentifiziert hat.

• Subject identifiziert den Benutzer (NameID).
• Conditions legen den Gültigkeitszeitraum und die vorgesehene Audience fest.
• AuthnStatement dokumentiert, wie und wann die Authentifizierung erfolgt ist.
• AttributeStatement übermittelt Rollen, E-Mail-Adressen und Gruppen-Claims.

Das häufigste Muster ist der SP-initiierte SSO-Flow.

• Der Benutzer ruft den SP auf. Dieser erzeugt eine AuthnRequest und leitet den Benutzer zum IdP weiter.
• Der IdP authentifiziert den Benutzer und sendet per POST eine signierte Response an den Assertion Consumer Service (ACS) des SP zurück.
• Der SP validiert die Assertion und erstellt eine lokale Sitzung.

Die Sicherheit von SAML beruht auf digitalen XML-Signaturen. Der IdP signiert die Assertion und/oder die Response mit seinem privaten Schlüssel. Der SP prüft die Signatur mit dem vertrauenswürdigen Zertifikat.

• Signieren Sie die Assertion selbst und nicht nur die äußere Response.
• Prüfen Sie die Signatur anhand eines gepinnten IdP-Zertifikats aus den Metadaten, nicht anhand eines in der Nachricht eingebetteten Zertifikats.

Die meisten SAML-Angriffe zielen auf die Logik der Signaturvalidierung.

XML Signature Wrapping ist die Angriffsklasse für SAML-Signaturen. Der Angreifer lässt ein gültig signiertes Element bestehen, fügt aber eine zweite, gefälschte Assertion hinzu, die die Anwendungslogik tatsächlich liest.

• Die Signatur wird weiterhin anhand des ursprünglichen Fragments erfolgreich geprüft.
• Die Geschäftslogik verarbeitet jedoch die eingeschleuste, unsignierte Assertion.

Abhilfe: Verwenden Sie eine gehärtete SAML-Bibliothek, validieren Sie, dass das signierte Element tatsächlich verarbeitet wird, und lehnen Sie Dokumente mit mehreren oder mehrdeutigen Assertions ab.

Eine Assertion muss an den vorgesehenen SP gebunden sein. SAML stellt dafür ausdrückliche Einschränkungen bereit.

• AudienceRestriction benennt die Entity-ID des SP, für den die Assertion gültig ist.
• Recipient in SubjectConfirmation muss mit der ACS-URL übereinstimmen.

Der SP muss diese Einschränkungen erzwingen. Wird die Audience nicht geprüft, kann eine für eine App ausgestellte Assertion bei einer anderen erneut verwendet werden.

Assertions sind kurzlebige, nur einmal verwendbare Zugangsdaten. SPs müssen dies erzwingen.

• Berücksichtigen Sie NotBefore und NotOnOrAfter mit einer engen Toleranz für Uhrabweichungen.
• Verfolgen Sie die ID der Assertion und lehnen Sie jede Wiederverwendung innerhalb des Gültigkeitszeitraums ab.
• Setzen Sie TLS für den ACS-Endpunkt voraus.

Ohne Replay-Verfolgung kann eine abgefangene Assertion vor ihrem Ablauf erneut eingereicht werden.

Föderation skaliert SSO über Organisationsgrenzen hinweg, teilweise über Hubs oder Broker, die zwischen Protokollen übersetzen.

• Jede Vertrauensbeziehung ist eine potenzielle Schwachstelle: Ein kompromittierter IdP kann sich als jeder Benutzer ausgeben.
• Identity Broker können SAML und OIDC miteinander verbinden, was ein sorgfältiges Claim-Mapping erfordert.

Wenden Sie auf das Attribut-Mapping das Prinzip der geringsten Rechte an und überwachen Sie unerwartete neue SP-Registrierungen.

Wiederkehrende SAML-Fehlerzustände, die Sie überprüfen sollten:

• Signatur nicht verifiziert oder Response signiert, Assertion jedoch nicht.
• Anfällig für XML Signature Wrapping.
• Prüfungen von Audience und Recipient fehlen.
• Kein Replay-Schutz oder übermäßig lange Gültigkeitszeiträume.
• Parsing von XML External Entities (XXE) auf dem SP.
• Das in der Nachricht eingebettete Zertifikat wird anstelle festgelegter Metadaten als vertrauenswürdig eingestuft.

Beide ermöglichen SSO, unterscheiden sich jedoch in ihrem Aufbau.

• SAML verwendet XML sowie Browser-POST- und Redirect-Bindings und ist im Enterprise- und Workforce-Umfeld weit verbreitet; außerdem gibt es ausgereifte Tools.
• OIDC verwendet JSON/JWT, ist REST-freundlich und eignet sich besser für mobile Anwendungen und SPAs.

Viele Organisationen setzen beide Protokolle ein. Sicherheitsteams sollten die Regeln zur Validierung von Assertions für das jeweils verwendete Protokoll kennen, da sich die Angriffsfläche unterscheidet.

Wählen Sie die beste Abwehrmaßnahme gegen den beschriebenen Angriff.

Die wichtigsten Erkenntnisse:

• SAML ist ein XML-basiertes Enterprise-SSO zwischen einem IdP und einem SP, bei dem signierte Assertions verwendet werden.
• Die Sicherheit hängt von der korrekten Validierung der XML-Signatur anhand eines festgelegten Zertifikats ab.
• Schützen Sie sich gegen XML Signature Wrapping, Replay-Angriffe und XXE.
• Erzwingen Sie immer Einschränkungen für Audience und Recipient sowie Gültigkeitszeiträume.
• Föderation skaliert Vertrauen, vergrößert aber auch den Schadensradius eines kompromittierten IdP.