Wikibrief

Security Assertion Markup Language

Artikel bearbeiten
XML-basiertes Format und Protokoll für den Austausch von Authentifizierungs- und Autorisierungsdaten zwischen Parteien

Die Security Assertion Markup Language ( SAML, ausgesprochen SAM-el) 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 Sicherheitsaussagen (Anweisungen, mit denen Dienstanbieter Zugriffssteuerungsentscheidungen treffen).SAML ist auch:

  • Eine Reihe von XML-basierten Protokollnachrichten
  • Eine Reihe von Protokollnachrichtenbindungen
  • Eine Reihe von Profilen (unter Verwendung aller oben genannten)

Ein wichtiger Anwendungsfall für SAML-Adressen ist das Single Sign-On (SSO) des Webbrowsers. Single Sign-On ist innerhalb einer Sicherheitsdomäne (z. B.mithilfe von Cookies )relativ einfach durchzuführen. DieAusweitung von SSO auf Sicherheitsdomänen ist jedoch schwieriger und führt zur Verbreitung nicht interoperabler proprietärer Technologien.Das SSO-Profil des SAML-Webbrowsers wurde spezifiziert und standardisiert, um die Interoperabilität zu fördern.

Inhalt

  • 1 Übersicht
  • 2 Geschichte
  • 3 Versionen
  • 4 Design
    • 4.1 Behauptungen
    • 4.2 Protokolle
    • 4.3 Bindungen
    • 4.4 Profile
    • 4.5 Sicherheit
  • 5 Verwenden
  • 6 Siehe auch
  • 7 Referenzen
  • 8 Externe Links

Überblick

Die SAML-Spezifikation definiert drei Rollen: den Principal (normalerweise ein menschlicher Benutzer), den Identitätsanbieter (IdP) und den Dienstanbieter (SP).In dem von SAML angesprochenen primären Anwendungsfall fordert der Principal einen Dienst vom Dienstanbieter an.Der Dienstanbieter fordert vom Identitätsanbieter eine Authentifizierungsbestätigung an und erhält diese.Auf der Grundlage dieser Behauptung kann der Dienstanbieter eine Zugriffssteuerungsentscheidung treffen, dh er kann entscheiden, ob der Dienst für den verbundenen Prinzipal ausgeführt werden soll.

Im Zentrum der SAML-Behauptung steht ein Thema (ein Prinzipal im Kontext einer bestimmten Sicherheitsdomäne), über das etwas behauptet wird.Das Thema ist normalerweise (aber nicht unbedingt) ein Mensch.Wie in der technischen Übersicht zu SAML V2.0 werden die Begriffe Betreff und Prinzipal in diesem Dokument synonym verwendet.

Vor der Übermittlung der subjektbasierten Zusicherung an den SP fordert der IdP möglicherweise einige Informationen vom Principal an, z. B. einen Benutzernamen und ein Kennwort, um den Principal zu authentifizieren.SAML gibt den Inhalt der Zusicherung an, die vom IdP an den SP übergeben wird.In SAML kann ein Identitätsanbieter vielen Dienstanbietern SAML-Zusicherungen bereitstellen.In ähnlicher Weise kann sich ein SP auf Aussagen vieler unabhängiger IdPs verlassen und diesen vertrauen.

SAML gibt die Authentifizierungsmethode beim Identitätsanbieter nicht an.Der IdP verwendet möglicherweise einen Benutzernamen und ein Kennwort oder eine andere Form der Authentifizierung, einschließlich der Multi-Faktor-Authentifizierung. Ein Verzeichnisdienst wie RADIUS, LDAP oder Active Directory, mit dem sich Benutzer mit einem Benutzernamen und einem Kennwort anmelden können, ist eine typische Quelle für Authentifizierungstoken bei einem Identitätsanbieter.Die beliebten Internet-Dienste für soziale Netzwerke bieten auch Identitätsdienste, die theoretisch zur Unterstützung des SAML-Austauschs verwendet werden könnten.

Geschichte

Geschichte von SAML (2002-2005)

Das OASIS Security Services Technical Committee (SSTC), das im Januar 2001 zum ersten Mal zusammentrat, wurde beauftragt, "ein XML-Framework für den Austausch von Authentifizierungs- und Autorisierungsinformationen zu definieren".Zu diesem Zweck wurde in den ersten beiden Monaten dieses Jahres folgendes geistiges Eigentum zum SSTC beigetragen:

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

Aufbauend auf diesen ersten Beiträgen kündigte OASIS im November 2002 die Spezifikation Security Assertion Markup Language (SAML) V1.0 als OASIS-Standard an.

In der Zwischenzeit schlug die Liberty Alliance, ein großes Konsortium aus Unternehmen, gemeinnützigen Organisationen und Regierungsorganisationen, eine Erweiterung des SAML-Standards vor, das als Liberty Identity Federation Framework (ID-FF) bezeichnet wird.Wie sein SAML-Vorgänger schlug Liberty ID-FF ein standardisiertes, domänenübergreifendes, webbasiertes Single-Sign-On-Framework vor.Darüber hinaus beschrieb Liberty einen Vertrauenskreis, in dem jeder teilnehmenden Domäne vertraut wird, um die zur Identifizierung eines Benutzers verwendeten Prozesse, den Typ des verwendeten Authentifizierungssystems und alle mit den resultierenden Authentifizierungsanmeldeinformationen verbundenen Richtlinien genau zu dokumentieren.Andere Mitglieder des Vertrauenskreises könnten diese Richtlinien dann prüfen, um festzustellen, ob sie solchen Informationen vertrauen sollen.

Während Liberty ID-FF entwickelte, begann der SSTC mit der Arbeit an einem geringfügigen Upgrade auf den SAML-Standard.Die resultierende SAML V1.1-Spezifikation wurde im September 2003 vom SSTC ratifiziert. Im November desselben Jahres trug Liberty ID-FF 1.2 zu OASIS bei und säte damit die Samen für die nächste Hauptversion von SAML.Im März 2005 wurde SAML V2.0 als OASIS-Standard angekündigt.SAML V2.0 repräsentiert die Konvergenz von Liberty ID-FF und proprietären Erweiterungen, die vom Shibboleth- Projekt bereitgestellt wurden, sowie frühen Versionen von SAML selbst.Die meisten SAML-Implementierungen unterstützen V2.0, während viele aus Gründen der Abwärtskompatibilität weiterhin V1.1 unterstützen.Bis Januar 2008 wurde die Bereitstellung von SAML V2.0 in Regierungs-, Hochschul- und Handelsunternehmen weltweit üblich.

Versionen

SAML wurde seit V1.0 einer kleinen und einer großen Revision 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 hat im September 2003 ihr Identity Federation Framework (ID-FF) zum OASIS SSTC beigetragen:

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

Die Versionen 1.0 und 1.1 von SAML sind ähnlich, obwohl kleine Unterschiede bestehen. Die Unterschiede zwischen SAML 2.0 und SAML 1.1 sind jedoch erheblich.Obwohl die beiden Standards denselben Anwendungsfall behandeln, ist SAML 2.0 nicht mit seinem Vorgänger kompatibel.

Obwohl ID-FF 1.2 als Grundlage für SAML 2.0 zu OASIS beigetragen wurde, gibt es einige wichtige Unterschiede zwischen SAML 2.0 und ID-FF 1.2.Insbesondere sind die beiden Spezifikationen trotz ihrer gemeinsamen Wurzeln nicht kompatibel.

Design

SAML basiert auf einer Reihe bestehender Standards:

  • Extensible Markup Language (XML): Die meisten SAML-Austausche werden in einem standardisierten XML-Dialekt ausgedrückt, der die Wurzel für den Namen SAML (Security Assertion Markup Language) darstellt.
  • XML-Schema (XSD): SAML-Zusicherungen und -Protokolle werden (teilweise) mithilfe des XML-Schemas angegeben.
  • XML-Signatur : Sowohl SAML 1.1 als auch SAML 2.0 verwenden digitale Signaturen (basierend auf dem XML-Signaturstandard) zur Authentifizierung und Nachrichtenintegrität.
  • XML-Verschlüsselung : Mit der XML-Verschlüsselung bietet SAML 2.0 Elemente für verschlüsselte Namenskennungen, verschlüsselte Attribute und verschlüsselte Zusicherungen (SAML 1.1 verfügt nicht über Verschlüsselungsfunktionen).Es wird berichtet, dass die XML-Verschlüsselung schwerwiegende Sicherheitsbedenken aufweist.
  • Hypertext Transfer Protocol (HTTP): SAML stützt sich stark auf HTTP als Kommunikationsprotokoll.
  • SOAP : SAML gibt die Verwendung von SOAP an, insbesondere SOAP 1.1.

SAML definiert XML-basierte Zusicherungen und Protokolle, Bindungen und Profile.Der Begriff SAML Core bezieht sich auf die allgemeine Syntax und Semantik von SAML-Zusicherungen sowie auf das Protokoll, mit dem diese Zusicherungen von einer Systemeinheit an eine andere angefordert und übertragen werden. Das SAML-Protokoll bezieht sich auf das, was übertragen wird, nicht wie (letzteres wird durch die Wahl der Bindung bestimmt).Daher definiert SAML Core "nackte" SAML-Zusicherungen zusammen mit SAML-Anforderungs- und Antwortelementen.

Eine SAML-Bindung bestimmt, wie SAML-Anforderungen und -Antworten auf Standardnachrichten- oder Kommunikationsprotokolle abgebildet werden.Eine wichtige (synchrone) Bindung ist die SAML SOAP-Bindung.

Ein SAML-Profil ist eine konkrete Manifestation eines definierten Anwendungsfalls unter Verwendung einer bestimmten Kombination von Behauptungen, Protokollen und Bindungen.

Behauptungen

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

 lt;saml:Assertion...gt;..lt;/saml:Assertiongt;

Eine vertrauende Partei interpretiert eine Behauptung lose wie folgt:

Die Behauptung A wurde zum Zeitpunkt t vom Emittenten R in Bezug auf das Thema S ausgestellt, sofern die Bedingungen C gültig sind.

SAML-Zusicherungen werden normalerweise von Identitätsanbietern an Dienstanbieter übertragen.Zusicherungen enthalten Aussagen, mit denen Dienstanbieter Zugriffssteuerungsentscheidungen treffen.SAML bietet drei Arten von Anweisungen:

  1. Authentifizierungsanweisungen
  2. Attributanweisungen
  3. Erklärungen zur Autorisierungsentscheidung

Authentifizierungsanweisungen bestätigen dem Dienstanbieter, dass sich der Principal tatsächlich zu einem bestimmten Zeitpunkt beim Identitätsanbieter unter Verwendung einer bestimmten Authentifizierungsmethode authentifiziert hat.Andere Informationen über den authentifizierten Principal (als Authentifizierungskontext bezeichnet) können in einer Authentifizierungsanweisung offengelegt werden.

Eine Attributanweisung bestätigt, dass ein Prinzipal bestimmten Attributen zugeordnet ist.Ein Attribut ist einfach ein Name-Wert-Paar. Vertrauende Parteien verwenden Attribute, um Entscheidungen zur Zugriffskontrolle zu treffen.

In einer Autorisierungsentscheidungserklärung wird bestätigt, dass ein Auftraggeber die Aktion A für die Ressource R ausführen darf,wenn Beweise E vorliegen.Die Aussagekraft von Genehmigungsentscheidungserklärungen in SAML ist absichtlich eingeschränkt.Fortgeschrittenere Anwendungsfälle sollten stattdessen XACML verwenden.

Protokolle

SAML-Protokollantwort

Ein SAML- Protokoll beschreibt, wie bestimmte SAML-Elemente (einschließlich Zusicherungen) in SAML-Anforderungs- und -Antwortelementen gepackt werden, und gibt die Verarbeitungsregeln an, denen SAML-Entitäten beim Erstellen oder Verwenden dieser Elemente folgen müssen.Ein SAML-Protokoll ist größtenteils ein einfaches Anforderungs-Antwort-Protokoll.

Der wichtigste Typ der SAML-Protokollanforderung wird als Abfrage bezeichnet. Ein Dienstanbieter stellt eine Anfrage direkt an einen Identitätsanbieter über einen sicheren Rückkanal.Daher sind Abfragenachrichten normalerweise an SOAP gebunden.

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

  1. Authentifizierungsabfrage
  2. Attributabfrage
  3. Abfrage der Autorisierungsentscheidung

Das Ergebnis einer Attributabfrage ist eine SAML-Antwort, die eine Zusicherung enthält, die selbst eine Attributanweisung enthält.Im SAML 2.0-Thema finden Sie ein Beispiel für die Abfrage / Antwort von Attributen.

Über Abfragen hinaus gibt SAML 1.1 keine anderen Protokolle an.

SAML 2.0 erweitert den Begriff des Protokolls erheblich.Die folgenden Protokolle werden in SAML 2.0 Core ausführlich beschrieben:

  • Assertion Query and Request Protocol
  • Authentifizierungsanforderungsprotokoll
  • Artefakt-Auflösungsprotokoll
  • Name Identifier Management Protocol
  • Single Logout-Protokoll
  • Name Identifier Mapping Protocol

Die meisten dieser Protokolle sind neu in SAML 2.0.

Bindungen

SAML über SOAP über HTTP

Eine SAML- Bindung ist eine Zuordnung einer SAML-Protokollnachricht zu Standardnachrichtenformaten und / oder Kommunikationsprotokollen.Beispielsweise gibt die SAML-SOAP-Bindung an, wie eine SAML-Nachricht in einem SOAP-Umschlag gekapselt ist, der selbst an eine HTTP-Nachricht gebunden ist.

SAML 1.1 gibt nur eine Bindung an, die SAML SOAP-Bindung.Neben SOAP sind in SAML 1.1 Webbrowser-SSO die Vorläufer der HTTP-POST-Bindung, der HTTP-Umleitungsbindung und der HTTP-Artefaktbindung impliziert.Diese sind jedoch nicht explizit definiert und werden nur in Verbindung mit SAML 1.1 Web Browser SSO verwendet.Der Begriff der Bindung ist erst mit SAML 2.0 vollständig entwickelt.

SAML 2.0 trennt das Bindungskonzept vollständig vom zugrunde liegenden Profil.Tatsächlich gibt es in SAML 2.0 eine brandneue Bindungsspezifikation, die die folgenden eigenständigen Bindungen definiert:

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

Diese Reorganisation bietet enorme Flexibilität: Am Beispiel eines Webbrowser-SSO allein kann ein Dienstanbieter aus vier Bindungen (HTTP-Umleitung, HTTP-POST und zwei Varianten von HTTP-Artefakt) auswählen, während der Identitätsanbieter über drei Bindungsoptionen (HTTP-POST plus) verfügt zwei Formen von HTTP-Artefakten) für insgesamt zwölf (12) mögliche Bereitstellungen des SAML 2.0-Webbrowser-SSO-Profils.

Profile

Ein SAML- Profil beschreibt detailliert, wie SAML-Zusicherungen, -Protokolle und -Bindungen kombiniert werden, um einen definierten Anwendungsfall zu unterstützen.Das wichtigste SAML-Profil ist das Webbrowser-SSO-Profil.

SAML 1.1 gibt zwei Formen von Webbrowser-SSO an, das Browser- / Artefaktprofil und das Browser- / POST-Profil.Letzterer übergibt Zusicherungen als Wert, während Browser / Artefakt Zusicherungen als Referenz übergibt.Infolgedessen erfordert Browser / Artefakt einen Rückkanal-SAML-Austausch über SOAP.In SAML 1.1 beginnen alle Flows der Einfachheit halber mit einer Anforderung beim Identitätsanbieter.Proprietäre Erweiterungen des von IdP initiierten Basisflusses wurden vorgeschlagen (zum Beispielvon Shibboleth ).

Das Webbrowser-SSO-Profil wurde für SAML 2.0 komplett überarbeitet.Konzeptionell sind SAML 1.1 Browser / Artifact und Browser / POST Sonderfälle von SAML 2.0 Webbrowser SSO.Letzteres ist aufgrund des neuen "Plug-and-Play" -Bindungsdesigns von SAML 2.0 wesentlich flexibler als sein Gegenstück zu SAML 1.1.Im Gegensatz zu früheren Versionen beginnen SAML 2.0-Browserflüsse mit einer Anfrage beim Dienstanbieter.Dies bietet eine größere Flexibilität, aber SP-initiierte Flows führen natürlich zu dem sogenannten Identity Provider Discovery- Problem, auf das sich heute viele Forschungsarbeiten konzentrieren.Zusätzlich zum Webbrowser-SSO führt SAML 2.0 zahlreiche neue Profile ein:

  • SSO-Profile
    • Webbrowser-SSO-Profil
    • Erweitertes Client- oder Proxy-Profil (ECP)
    • Erkennungsprofil des Identitätsanbieters
    • Single Logout-Profil
    • Name Identifier Management Profile
  • Artefaktauflösungsprofil
  • Assertion Query / Request Profile
  • Zuordnungsprofil für Namenskennung
  • SAML-Attributprofile

Neben dem SAML-Webbrowser-SSO-Profil enthalten einige wichtige Profile von Drittanbietern von SAML:

  • Technisches Komitee für OASIS Web Services Security (WSS)
  • Liberty Alliance
  • Technisches Komitee für OASIS eXtensible Access Control Markup Language (XACML)

Sicherheit

Die SAML-Spezifikationen empfehlen und schreiben in einigen Fällen verschiedene Sicherheitsmechanismen vor:

Anforderungen werden häufig in Bezug auf (gegenseitige) Authentifizierung, Integrität und Vertraulichkeit formuliert, sodass Implementierern und Bereitstellern die Wahl des Sicherheitsmechanismus überlassen bleibt.

Benutzen

Der primäre SAML-Anwendungsfall heißt Web Browser Single Sign-On (SSO). Ein Benutzer verwendet einen Benutzeragenten (normalerweise einen Webbrowser), um eine Webressource anzufordern, die von einem SAML- Dienstanbieter geschützt wird.Der Dienstanbieter, der die Identität des anfordernden Benutzers wissen möchte, sendetüber den Benutzeragenteneine Authentifizierungsanforderung an einen SAML- Identitätsanbieter. Der resultierende Protokollfluss ist in der folgenden Abbildung dargestellt.

Single Sign-On mit SAML in einem Webbrowser
1. Fordern Sie die Zielressource beim SP an (nur SAML 2.0).
Der Principal (über einen HTTP-Benutzeragenten) fordert beim Dienstanbieter eine Zielressource an:
https://sp.example.com/myresource
Der Dienstanbieter führt im Namen der Zielressource eine Sicherheitsüberprüfung durch.Wenn beim Dienstanbieter bereits ein gültiger Sicherheitskontext vorhanden ist, überspringen Sie die Schritte 2 bis 7.
2. Weiterleiten an den SSO-Dienst am IdP (nur SAML 2.0)
Der Dienstanbieter bestimmt den bevorzugten Identitätsanbieter des Benutzers (auf nicht spezifizierte Weise) und leitet den Benutzeragenten an den SSO-Dienst beim Identitätsanbieter weiter:
https://idp.example.org/SAML2/SSO/Redirect?SAMLRequest=request
Der Wert desSAMLRequest Parameters (durch denrequest obigenPlatzhalter gekennzeichnet) ist die Base64- Codierung eines deflationierten lt;samlp:AuthnRequestgt;Elements.
3. Fordern Sie den SSO-Dienst beim IdP an (nur SAML 2.0).
Der Benutzeragent gibt ab Schritt 2 eine GET-Anforderung an den SSO-Dienst unter der URL aus. Der SSO-Dienst verarbeitet dieAuthnRequest (über denSAMLRequest URL-Abfrageparametergesendete) und führt eine Sicherheitsüberprüfung durch.Wenn der Benutzer keinen gültigen Sicherheitskontext hat, identifiziert der Identitätsanbieter den Benutzer (Details weggelassen).
4. Antworten Sie mit einem XHTML-Formular
Der SSO-Dienst überprüft die Anforderung und antwortet mit einem Dokument, das ein XHTML-Formular enthält:
lt;form method="post" action="https://sp.example.com/SAML2/SSO/POST"...gt;lt;input type="hidden" name="SAMLResponse" value="response" /gt;...lt;input type="submit" value="Submit" /gt;lt;/formgt;
Der Wert desSAMLResponse Elements (oben mit dem Platzhalter gekennzeichnetresponse) ist die base64-Codierung eineslt;samlp:Responsegt; Elements.
5. Fordern Sie den Assertion Consumer Service beim SP an
Der Benutzeragent sendet eine POST-Anforderung an den Assertion-Consumer-Service beim Dienstanbieter.Der Wert desSAMLResponse Parameters wird in Schritt 4 dem XHTML-Formular entnommen.
6. Zur Zielressource umleiten
Der Assertion Consumer Service verarbeitet die Antwort, erstellt einen Sicherheitskontext beim Service Provider und leitet den Benutzeragenten an die Zielressource weiter.
7. Fordern Sie die Zielressource erneut beim SP an
Der Benutzeragent fordert die Zielressource (erneut) beim Dienstanbieter an:
https://sp.example.com/myresource
8. Antworten Sie mit der angeforderten Ressource
Da ein Sicherheitskontext vorhanden ist, gibt der Dienstanbieter die Ressource an den Benutzeragenten zurück.

In SAML 1.1 beginnt der Ablauf mit einer Anforderung an den standortübergreifenden Übertragungsdienst des Identitätsanbieters in Schritt 3.

Im obigen Beispielablauf sind alle dargestellten Austausche Front-Channel-Austausche, dh ein HTTP-Benutzeragent (Browser) kommuniziert bei jedem Schritt mit einer SAML-Entität.Insbesondere gibt es keinen Rückkanalaustausch oderkeinedirekte Kommunikation zwischen dem Dienstanbieter und dem Identitätsanbieter.Front-Channel-Austausch führt zu einfachen Protokollflüssen, bei denen alle Nachrichtenmithilfe einer einfachen HTTP-Bindung (GET oder POST) als Wert übergeben werden.In der Tat wird der im vorherigen Abschnitt beschriebene Ablauf manchmal als Lightweight Web Browser SSO-Profil bezeichnet.

Alternativ können Nachrichten zur Erhöhung der Sicherheit oder des Datenschutzes als Referenz weitergeleitet werden.Beispielsweise kann ein Identitätsanbieter einen Verweis auf eine SAML-Zusicherung (als Artefakt bezeichnet)bereitstellen,anstatt die Zusicherung direkt über den Benutzeragenten zu übertragen.Anschließend fordert der Dienstanbieter die tatsächliche Bestätigung über einen Rückkanal an.Ein solcher Rückkanalaustausch wird als SOAP- Nachrichtenaustausch (SAML über SOAP über HTTP) angegeben.Im Allgemeinen wird jeder SAML-Austausch über einen sicheren Rückkanal als SOAP-Nachrichtenaustausch durchgeführt.

Auf dem Rückkanal gibt SAML die Verwendung von SOAP 1.1 an.Die Verwendung von SOAP als Bindungsmechanismus ist jedoch optional.Bei jeder SAML-Bereitstellung wird ausgewählt, welche Bindungen geeignet sind.

Siehe auch

Verweise

Externe Links

Contacts: mail@wikibrief.org
Der Inhalt ist unter der CC BY-SA 3.0-Lizenz verfugbar (sofern nicht anders angegeben).