SAML

Security Assertion Markup Language ( SAML , ausgesprochen SAM-el , / ˈsæməl / ) ^{[ 1} ] ist ein offener Standard für den Austausch von ^{Authentifizierungs-} und Autorisierungsdaten zwischen Parteien, insbesondere zwischen einem Identitätsanbieter und einem Dienstanbieter . SAML ist eine XML -basierte Auszeichnungssprache für Sicherheitszusicherungen (Aussagen , die Dienstanbieter zur Entscheidungsfindung über die Zugriffskontrolle verwenden). SAML ist außerdem:

• Ein Satz von XML-basierten Protokollnachrichten
• Ein Satz von Protokollnachrichtenbindungen
• Ein Satz von Profilen (unter Verwendung aller oben genannten Elemente)

Ein wichtiger Anwendungsfall von SAML ist das Single Sign-On (SSO) von Webbrowsern . Innerhalb einer Sicherheitsdomäne lässt sich Single Sign-On relativ einfach realisieren (z. B. mithilfe von Cookies ). Die Erweiterung von SSO über Sicherheitsdomänen hinweg gestaltet sich jedoch schwieriger und führte zur Verbreitung nicht interoperabler proprietärer Technologien. Das SAML-Webbrowser-SSO-Profil wurde spezifiziert und standardisiert, um die Interoperabilität zu fördern. ^{[ 2 ]} In der Praxis wird SAML SSO am häufigsten zur Authentifizierung bei cloudbasierter Unternehmenssoftware eingesetzt. ^{[ 3 ]}

Die SAML-Spezifikation definiert drei Rollen: den Prinzipal (in der Regel ein menschlicher Benutzer), den Identitätsanbieter (IdP) und den Dienstanbieter (SP). Im primären Anwendungsfall von SAML fordert der Prinzipal einen Dienst vom Dienstanbieter an. Der Dienstanbieter fordert daraufhin eine Authentifizierungsbestätigung vom Identitätsanbieter an und erhält diese. Auf Basis dieser Bestätigung kann der Dienstanbieter eine Zugriffsentscheidung treffen , d. h. er kann entscheiden, ob er den Dienst für den verbundenen Prinzipal ausführt.

Kern der SAML-Assertion ist ein Subjekt (ein Prinzipal innerhalb einer bestimmten Sicherheitsdomäne), über das eine Aussage getroffen wird. Das Subjekt ist üblicherweise (aber nicht notwendigerweise) ein Mensch. Wie in der technischen Übersicht zu SAML 2.0 ^{[ 4 ]} werden die Begriffe Subjekt und Prinzipal synonym verwendet.

Bevor der Identitätsanbieter die subjektbasierte Assertion an den Dienstanbieter übermittelt, kann er vom Prinzipal Informationen (z. B. Benutzername und Passwort) zur Authentifizierung anfordern. SAML spezifiziert den Inhalt der Assertion, die vom Identitätsanbieter an den Dienstanbieter übergeben wird. In SAML kann ein Identitätsanbieter SAML-Assertions an mehrere Dienstanbieter bereitstellen. Ebenso kann ein Dienstanbieter (SP) auf Assertions von mehreren unabhängigen Identitätsanbietern (IdP) vertrauen. ^{[ 5 ]}

SAML legt die Authentifizierungsmethode des Identitätsanbieters nicht fest. Dieser kann einen Benutzernamen und ein Passwort oder eine andere Authentifizierungsform verwenden, beispielsweise Multi-Faktor-Authentifizierung oder Kerberos -Tickets. Ein Verzeichnisdienst wie RADIUS oder LDAP , der die Anmeldung mit Benutzernamen und Passwort ermöglicht, ist eine typische Quelle für Authentifizierungstoken bei einem Identitätsanbieter. ^{[ 6 ]} Auch die gängigen sozialen Netzwerke im Internet bieten Identitätsdienste an, die theoretisch zur Unterstützung von SAML-Austauschen genutzt werden könnten.

Das Security Services Technical Committee (SSTC) der Organization for the Advancement of Structured Information Standards (OASIS) , das im Januar 2001 erstmals zusammentrat, wurde mit dem Auftrag gegründet, „ein XML-Framework für den Austausch von Authentifizierungs- und Autorisierungsinformationen zu definieren“. ^{[ 7 ]} Zu diesem Zweck wurden dem SSTC in den ersten beiden Monaten jenes Jahres folgende geistige Eigentumsrechte zur Verfügung gestellt:

• Security Services Markup Language (S2ML) von Netegrity
• AuthXML von Securant
• XML Trust Assertion Service Specification (X-TASS) von VeriSign
• Information Technology Markup Language (ITML) von Jamcracker

Aufbauend auf diesen ersten Beiträgen kündigte OASIS im November 2002 die Security Assertion Markup Language (SAML) 1.0-Spezifikation als OASIS-Standard an. ^{[ 8 ]}

Die Liberty Alliance , ein großes Konsortium aus Unternehmen, gemeinnützigen Organisationen und Regierungsbehörden, schlug unterdessen eine Erweiterung des SAML-Standards vor: das Liberty Identity Federation Framework (ID-FF). ^{[ 9 ]} Wie sein Vorgänger SAML bot auch Liberty ID-FF ein standardisiertes, domänenübergreifendes, webbasiertes Single-Sign-On-Framework. Liberty beschrieb zudem einen Vertrauenskreis , in dem jede teilnehmende Domäne die Prozesse zur Benutzeridentifizierung, das verwendete Authentifizierungssystem und alle zugehörigen Richtlinien für die Anmeldeinformationen präzise dokumentiert. Andere Mitglieder des Vertrauenskreises können diese Richtlinien prüfen und entscheiden, ob sie den Informationen vertrauen. ^{[ 10 ]}

Während Liberty ID-FF entwickelte, begann das SSTC mit der Arbeit an einem kleineren Upgrade des SAML-Standards. Die daraus resultierende SAML-1.1-Spezifikation wurde im September 2003 vom SSTC ratifiziert. Im November desselben Jahres trug Liberty ID-FF 1.2 zu OASIS bei und legte damit den Grundstein für die nächste Hauptversion von SAML. Im März 2005 wurde SAML 2.0 als OASIS-Standard angekündigt. SAML 2.0 repräsentiert die Konvergenz von Liberty ID-FF und proprietären Erweiterungen des Shibboleth -Projekts sowie früheren Versionen von SAML selbst. Die meisten SAML-Implementierungen unterstützen Version 2.0, viele jedoch weiterhin Version 1.1 aus Gründen der Abwärtskompatibilität. Bis Januar 2008 waren SAML-2.0-Implementierungen weltweit in Behörden, Hochschulen und Unternehmen weit verbreitet. ^{[ 10 ]}

SAML wurde seit Version 1.0 einer kleineren und einer größeren Überarbeitung unterzogen.

• SAML 1.0 wurde im November 2002 als OASIS-Standard übernommen.
• SAML 1.1 wurde im September 2003 als OASIS-Standard ratifiziert.
• SAML 2.0 wurde im März 2005 zum OASIS-Standard.

Die Liberty Alliance steuerte ihr Identity Federation Framework (ID-FF) im September 2003 zum OASIS SSTC bei:

• ID-FF 1.1 wurde im April 2003 veröffentlicht.
• ID-FF 1.2 wurde im November 2003 fertiggestellt.

Die SAML-Versionen 1.0 und 1.1 ähneln sich trotz kleinerer Unterschiede ^{[ 11 ]} , die Unterschiede zwischen SAML 2.0 und SAML 1.1 sind jedoch erheblich. Obwohl beide Standards denselben Anwendungsfall abdecken, ist SAML 2.0 mit seinem Vorgänger inkompatibel.

Obwohl ID-FF 1.2 als Grundlage für SAML 2.0 zu OASIS beigetragen wurde, bestehen einige wichtige Unterschiede zwischen SAML 2.0 und ID-FF 1.2. Insbesondere sind die beiden Spezifikationen trotz ihrer gemeinsamen Wurzeln inkompatibel. ^{[ 10 ]}

SAML basiert auf einer Reihe bestehender Standards:

• Extensible Markup Language (XML): Die meisten SAML-Austausche werden in einem standardisierten Dialekt von XML ausgedrückt, der die Wurzel für den Namen SAML (Security Assertion Markup Language) ist.
• XML Schema (XSD): SAML-Assertions und -Protokolle werden (teilweise) mithilfe von XML Schema spezifiziert.
• XML-Signatur : Sowohl SAML 1.1 als auch SAML 2.0 verwenden digitale Signaturen (basierend auf dem XML-Signaturstandard) zur Authentifizierung und zur Gewährleistung der Nachrichtenintegrität.
• XML-Verschlüsselung : SAML 2.0 verwendet XML-Verschlüsselung und stellt Elemente für verschlüsselte Namensbezeichner, Attribute und Assertions bereit (SAML 1.1 bietet keine Verschlüsselungsfunktionen). Es wird berichtet, dass die XML-Verschlüsselung erhebliche Sicherheitsrisiken birgt. ^{[ 12 ] [ 13 ]}
• Hypertext Transfer Protocol (HTTP): SAML stützt sich in hohem Maße auf HTTP als Kommunikationsprotokoll.
• Simple Object Access Protocol (SOAP) : SAML spezifiziert die Verwendung von SOAP, insbesondere SOAP 1.1. ^{[ 14 ]}

SAML definiert XML-basierte Zusicherungen und Protokolle, Bindungen und Profile. Der Begriff SAML Core bezeichnet die allgemeine Syntax und Semantik von SAML-Zusicherungen sowie das Protokoll, das zum Anfordern und Übertragen dieser Zusicherungen zwischen Systemen verwendet wird. Das SAML-Protokoll beschreibt, was übertragen wird, nicht wie (Letzteres wird durch die Wahl der Bindung bestimmt). SAML Core definiert also „einfache“ SAML-Zusicherungen sowie die entsprechenden SAML-Anfrage- und Antwortelemente.

Eine SAML-Bindung legt fest, wie SAML-Anfragen und -Antworten auf Standard-Messaging- oder Kommunikationsprotokolle abgebildet werden. Eine wichtige (synchrone) Bindung ist die SAML-SOAP-Bindung.

Ein SAML-Profil ist eine konkrete Ausprägung eines definierten Anwendungsfalls unter Verwendung einer bestimmten Kombination von Assertions, Protokollen und Bindungen.

Eine SAML- Assertion enthält ein Paket mit Sicherheitsinformationen:

<saml:Assertion ...> ... </saml:Assertion> 

Grob gesagt interpretiert eine Partei, die sich auf eine Aussage verlässt, diese folgendermaßen:

Die Aussage A wurde zum Zeitpunkt t vom Emittenten R in Bezug auf Gegenstand S unter der Voraussetzung abgegeben, dass die Bedingungen C erfüllt sind.

SAML-Assertions werden üblicherweise von Identitätsanbietern an Dienstanbieter übertragen. Assertions enthalten Anweisungen , die Dienstanbieter für Zugriffskontrollentscheidungen verwenden. SAML stellt drei Arten von Anweisungen bereit:

1. Authentifizierungsanweisungen
2. Attributaussagen
3. Genehmigungsentscheidungen

Authentifizierungsanweisungen bestätigen dem Dienstanbieter, dass sich der Benutzer zu einem bestimmten Zeitpunkt mit einer bestimmten Authentifizierungsmethode beim Identitätsanbieter authentifiziert hat. Weitere Informationen über den authentifizierten Benutzer (der sogenannte Authentifizierungskontext ) können in einer Authentifizierungsanweisung offengelegt werden.

Eine Attributangabe besagt, dass ein Prinzipal bestimmten Attributen zugeordnet ist. Ein Attribut ist einfach ein Name-Wert-Paar . Vertrauende Parteien verwenden Attribute, um Zugriffskontrollentscheidungen zu treffen.

Eine Autorisierungsentscheidungserklärung besagt, dass ein Prinzipal berechtigt ist, Aktion A auf Ressource R durchzuführen, vorausgesetzt, es liegen Beweise E vor . Die Ausdrucksstärke von Autorisierungsentscheidungserklärungen in SAML ist bewusst eingeschränkt. Für komplexere Anwendungsfälle wird die Verwendung von XACML empfohlen .

Ein SAML- Protokoll beschreibt, wie bestimmte SAML-Elemente (einschließlich Assertions) in SAML-Anfrage- und Antwortelementen verpackt werden und legt die Verarbeitungsregeln fest, die SAML-Entitäten beim Erstellen oder Verwenden dieser Elemente befolgen müssen. Im Wesentlichen handelt es sich bei einem SAML-Protokoll um ein einfaches Anfrage-Antwort-Protokoll.

Die wichtigste Art von SAML-Protokollanfrage wird als Query bezeichnet . Ein Dienstanbieter sendet eine Anfrage direkt über einen sicheren Backchannel an einen Identitätsanbieter. Daher sind Query-Nachrichten typischerweise an SOAP gebunden.

Entsprechend den drei Arten von Anweisungen gibt es drei Arten von SAML-Abfragen:

1. Authentifizierungsanfrage
2. Attributabfrage
3. Autorisierungsentscheidungsanfrage

Das Ergebnis einer Attributabfrage ist eine SAML-Antwort, die eine Assertion enthält, welche wiederum eine Attributanweisung beinhaltet. Ein Beispiel für Attributabfrage und -antwort finden Sie im Thema SAML 2.0 .

Über Abfragen hinaus spezifiziert SAML 1.1 keine weiteren Protokolle.

SAML 2.0 erweitert den Protokollbegriff erheblich . Die folgenden Protokolle werden in SAML 2.0 Core detailliert beschrieben:

• Assertion Query and Request Protocol
• Authentifizierungsanforderungsprotokoll
• Artefaktauflösungsprotokoll
• Namensidentifikator-Verwaltungsprotokoll
• Single Logout Protokoll
• Namensidentifikator-Zuordnungsprotokoll

Die meisten dieser Protokolle sind neu in SAML 2.0 .

Eine SAML -Bindung ist eine Zuordnung einer SAML-Protokollnachricht zu standardisierten Nachrichtenformaten und/oder Kommunikationsprotokollen. Beispielsweise legt die SAML-SOAP-Bindung fest, wie eine SAML-Nachricht in einen SOAP-Envelope gekapselt wird, der wiederum an eine HTTP-Nachricht gebunden ist.

SAML 1.1 spezifiziert lediglich eine Bindung, die SAML-SOAP-Bindung. Zusätzlich zu SOAP sind in SAML 1.1 Webbrowser-SSO implizit die Vorläufer der HTTP-POST-Bindung, der HTTP-Redirect-Bindung und der HTTP-Artifact-Bindung enthalten. Diese sind jedoch nicht explizit definiert und werden nur in Verbindung mit SAML 1.1 Webbrowser-SSO verwendet. Das Konzept der Bindung wird erst mit SAML 2.0 vollständig ausgearbeitet.

SAML 2.0 trennt das Bindungskonzept vollständig vom zugrundeliegenden Profil. Tatsächlich gibt es in SAML 2.0 eine völlig neue Bindungsspezifikation , die die folgenden eigenständigen Bindungen definiert:

• SAML SOAP-Bindung (basierend auf SOAP 1.1)
• Reverse SOAP (PAOS) ​​Bindung
• HTTP-Weiterleitung (GET)-Bindung
• HTTP POST-Bindung
• HTTP-Artefaktbindung
• SAML-URI-Bindung

Diese Reorganisation bietet enorme Flexibilität: Nehmen wir nur das Beispiel Webbrowser-SSO: Ein Dienstanbieter kann zwischen vier Bindungen wählen (HTTP Redirect, HTTP POST und zwei Varianten von HTTP Artifact), während der Identitätsanbieter drei Bindungsoptionen hat (HTTP POST plus zwei Formen von HTTP Artifact), was insgesamt zwölf mögliche Bereitstellungen des SAML 2.0 Webbrowser-SSO-Profils ergibt.

Ein SAML- Profil beschreibt detailliert, wie SAML-Assertions, -Protokolle und -Bindings zusammenwirken, um einen definierten Anwendungsfall zu unterstützen. Das wichtigste SAML-Profil ist das Webbrowser-SSO-Profil.

SAML 1.1 spezifiziert zwei Formen von Webbrowser-SSO: das Browser/Artifact-Profil und das Browser/POST-Profil. Letzteres übergibt Assertions per Wert , während Browser/Artifact Assertions per Referenz übergibt . Daher benötigt Browser/Artifact einen SAML-Austausch über SOAP. In SAML 1.1 beginnen alle Abläufe aus Gründen der Einfachheit mit einer Anfrage beim Identitätsanbieter. Es wurden proprietäre Erweiterungen des grundlegenden, vom Identitätsanbieter initiierten Ablaufs vorgeschlagen (z. B. von Shibboleth ).

Das Webbrowser-SSO-Profil wurde für SAML 2.0 vollständig überarbeitet. Konzeptionell stellen SAML 1.1 Browser/Artifact und Browser/POST Spezialfälle von SAML 2.0 Webbrowser-SSO dar. Letzteres ist dank des neuen „Plug-and-Play“-Bindungsdesigns von SAML 2.0 deutlich flexibler als sein SAML 1.1-Pendant. Anders als in früheren Versionen beginnen SAML 2.0-Browser-Abläufe mit einer Anfrage beim Dienstanbieter. Dies bietet zwar mehr Flexibilität, führt aber naturgemäß zum sogenannten Identity Provider Discovery- Problem, das heute Gegenstand zahlreicher Forschungsarbeiten ist. Neben Webbrowser-SSO führt SAML 2.0 zahlreiche neue Profile ein:

• SSO-Profile
  • Webbrowser-SSO-Profil
  • Erweitertes Client- oder Proxy-Profil (ECP)
  • Identitätsanbieter-Erkennungsprofil
  • Profil für einmaliges Abmelden
  • Namensidentifikator-Verwaltungsprofil
• Artefaktauflösungsprofil
• Assertionsabfrage-/Anforderungsprofil
• Namensidentifikator-Zuordnungsprofil
• SAML-Attributprofile

Neben dem SAML-Webbrowser-SSO-Profil gehören zu den wichtigsten Drittanbieterprofilen von SAML:

• Technischer Ausschuss für Webdienstesicherheit (WSS) von OASIS
• Liberty Alliance
• Technisches Komitee für die OASIS eXtensible Access Control Markup Language (XACML)

Die SAML-Spezifikationen empfehlen und schreiben in einigen Fällen eine Vielzahl von Sicherheitsmechanismen vor:

• TLS  1.0+ für Transportsicherheit
• XML-Signatur und XML-Verschlüsselung für die Sicherheit auf Nachrichtenebene

Die Anforderungen werden oft in Bezug auf (gegenseitige) Authentifizierung, Integrität und Vertraulichkeit formuliert, wodurch die Wahl des Sicherheitsmechanismus den Implementierern und Anwendern überlassen wird.

Der primäre Anwendungsfall von SAML ist das sogenannte Single Sign-On (SSO) über Webbrowser . Ein Benutzer verwendet einen Browser (in der Regel einen User-Agent ), um eine durch einen SAML- Dienstanbieter geschützte Webressource anzufordern . Der Dienstanbieter, der die Identität des anfragenden Benutzers überprüfen möchte, sendet über den Browser eine Authentifizierungsanfrage an einen SAML- Identitätsanbieter . Der resultierende Protokollablauf ist im folgenden Diagramm dargestellt.

1. Fordern Sie die Zielressource beim Service Provider (SP) an (nur SAML 2.0)

Der Nutzer (über einen HTTPS-User-Agent) fordert eine Zielressource beim Dienstanbieter an:

https://sp.example.com/myresource

Der Dienstanbieter führt im Auftrag der Zielressource eine Sicherheitsprüfung durch. Falls beim Dienstanbieter bereits ein gültiger Sicherheitskontext existiert, können die Schritte 2–7 übersprungen werden.

2. Weiterleitung zum SSO-Dienst beim IdP (nur SAML 2.0)

Der Dienstanbieter ermittelt (auf nicht näher spezifizierte Weise) den bevorzugten Identitätsanbieter des Benutzers und leitet den Benutzeragenten zum SSO-Dienst des Identitätsanbieters weiter:

https://idp.example.org/SAML2/SSO/Redirect?SAMLRequest=request

Der Wert des SAMLRequestParameters (oben mit dem Platzhalter gekennzeichnet request) ist die Base64 -Kodierung eines deflatierten<samlp:AuthnRequest> Elements.

3. Fordern Sie den SSO-Dienst beim IdP an (nur SAML 2.0)

Der Benutzeragent sendet eine GET-Anfrage an den SSO-Dienst unter der in Schritt 2 angegebenen URL. Der SSO-Dienst verarbeitet die AuthnRequest(über den SAMLRequestURL-Abfrageparameter gesendeten) Daten und führt eine Sicherheitsprüfung durch. Verfügt der Benutzer nicht über einen gültigen Sicherheitskontext, identifiziert der Identitätsanbieter den Benutzer (Details werden hier nicht aufgeführt).

4. Antworten Sie mit einem XHTML-Formular

Der SSO-Dienst validiert die Anfrage und antwortet mit einem Dokument, das ein XHTML-Formular enthält:

< form method = "post" action = "https://sp.example.com/SAML2/SSO/POST" ... > < input type = "hidden" name = "SAMLResponse" value = "response" /> ... < input type = "submit" value = " Absenden" / > </form>

Der Wert des SAMLResponseElements ( responseoben durch den Platzhalter gekennzeichnet) ist die Base64-Kodierung eines <samlp:Response>Elements.

5. Beantragen Sie beim Service Provider (SP) den Kundenservice für Verbraucherbeschwerden.

Der Benutzeragent sendet eine POST-Anfrage an den Assertions-Consumer-Service des Dienstanbieters. Der Wert des SAMLResponseParameters wird aus dem XHTML-Formular in Schritt 4 übernommen.

6. Weiterleitung zur Zielressource

Der Assertions-Consumer-Service verarbeitet die Antwort, erstellt einen Sicherheitskontext beim Service Provider und leitet den User-Agent zur Zielressource weiter.

7. Fordern Sie die Zielressource erneut beim Service Provider an.

Der Benutzeragent fordert die Zielressource (erneut) beim Dienstanbieter an:

https://sp.example.com/myresource

8. Mit der angeforderten Ressource antworten.

Da ein Sicherheitskontext vorhanden ist, gibt der Dienstanbieter die Ressource an den Benutzeragenten zurück.

Bei SAML 1.1 beginnt der Ablauf mit einer Anfrage an den Inter-Site-Transfer-Dienst des Identitätsanbieters in Schritt 3.

Im obigen Beispielablauf handelt es sich bei allen dargestellten Transaktionen um Front-Channel-Transaktionen . Das heißt, ein HTTP-Benutzeragent (Browser) kommuniziert in jedem Schritt mit einer SAML-Entität. Es gibt insbesondere keine Back-Channel-Transaktionen oder direkte Kommunikation zwischen Dienstanbieter und Identitätsanbieter. Front-Channel-Transaktionen führen zu einfachen Protokollabläufen, bei denen alle Nachrichten per Wert über eine einfache HTTP-Anfrage (GET oder POST) übertragen werden. Der im vorherigen Abschnitt beschriebene Ablauf wird daher auch als Lightweight Webbrowser SSO Profile bezeichnet .

Alternativ können Nachrichten zur Erhöhung der Sicherheit oder des Datenschutzes auch per Referenz übermittelt werden . Beispielsweise kann ein Identitätsanbieter eine Referenz auf eine SAML-Assertion (ein sogenanntes Artefakt ) bereitstellen, anstatt die Assertion direkt über den Benutzeragenten zu übertragen. Anschließend fordert der Dienstanbieter die eigentliche Assertion über einen Backchannel an. Dieser Backchannel-Austausch wird als SOAP- Nachrichtenaustausch (SAML über SOAP über HTTP) spezifiziert. Generell wird jeder SAML-Austausch über einen sicheren Backchannel als SOAP-Nachrichtenaustausch durchgeführt.

Im Backchannel schreibt SAML die Verwendung von SOAP 1.1 vor. Die Verwendung von SOAP als Bindungsmechanismus ist jedoch optional. Jede SAML-Implementierung wählt die jeweils geeigneten Bindungen aus.

• SAML 2.0
• SAML-Metadaten
• SAML-basierte Produkte und Dienstleistungen
• Identitätsmanagement
• Identitätsmanagementsysteme
• Föderierte Identität
• Informationskarte
• WS-Föderation
• OAuth
• OpenID Connect

• Technischer Ausschuss für Sicherheitsdienste von OASIS
• Deckblätter: Security Assertion Markup Language (SAML)
• Wie man SAML studiert und lernt
• SAML verständlich erklärt
• Erster öffentlicher SAML 2.0-Identitätsanbieter
• Daniel Blum (2003). Federated ID gewinnt an Dynamik . IDG Network World Inc., S. 42.