SAML

SAML, die Security Assertion Markup Language, ist ein von OASIS standardisiertes XML-Framework zum Austausch von Sicherheitsinformationen. Es wird eine Dokumentenstruktur für Sicherheitsinformationen definiert, die die Interaktionen zwischen verschiedenen unabhängigen Services erlaubt. Dabei werden Sicherheitsbehauptungen, so genannte assertions benutzt. Teil des Standards sind weiterhin eine Anzahl von Request/Response-Protokollen für unterschiedliche Anwendungsfälle.

Motivation

Multi-Domain Web Single Sign-On ist einer der wichtigsten Anwendungsfälle von SAML. Dabei hat der Benutzer eine Login Session, das heißt einen Sicherheitskontext, bei seinem Identity Provider. Dazu muss dieser ein lokales Authentifizierungssystem bereitstellen. Um den Dienst eines Service Providers in Anspruch zu nehmen, ist bei diesem üblicherweise eine Authentifizierung notwendig. Ebenso ist bei jedem weiteren Service Provider eine erneute und völlig unabhängige Authentifizierung von Nöten. Das Konzept des Single Sign-On erlaubt es nun dem Benutzer sich einmal bei seinem Identity Provider zu authentifizieren und jede folgende Authentifizierung beim Service Provider durch den Identity Provider vornehmen zu lassen.

Viele Firmen bieten Single Sign-On Lösungen an. Problematisch ist dabei aber, dass die Sicherheitseigenschaften der auftretenden Interaktionen nicht standardisiert sind und somit jedes Produkt unterschiedlich stark geschützt ist. Des weiteren sind solche Lösungen üblicherweise nicht interoperabel, so dass die Wahl des Produkts eine Einschränkung bei der Wahl von Service und Identity Providern darstellt. Bei SAML sind hingegen Mindestanforderungen bezüglich der Sicherheit für verschiedene Transaktionstypen definiert sowie Interoperabilität durch eine standardisierte Dokumentenstruktur garantiert.

Komponenten

SAML besteht aus mehreren aufeinander aufbauenden Komponenten. Diese erlauben, wenn zusammengesetzt, eine Vielzahl von Anwendungsfällen. SAML Assertions beinhalten Aussagen einer Partei über ein Subjekt. Beispielsweise könnte eine Assertion aussagen, dass das Subjekt John Doe heißt und die E-Mail Adresse john.doe@example.com hat. Solche Assertions werden meist nur basierend auf einer Anfrage erstellt, können aber unter bestimmten Umständen auch initial an den Empfänger gesendet werden. Es gibt drei verschiedene Statements: Authentication, Attribute, Authorization Decision Statement. Die SAML Protokolle definieren Anfragen und Antworten einer korrekten Kommunikation mithilfe von SAML-Werkzeugen. Es gibt sechs verschiedene SAML-Protokolle, dazu gehört das Authentication Request Protocol, welches Anwendung im Web Single Sign-On Fall findet. Weitere wichtige Protokolle sind das Artifact Resolution Protocol und das Single Logout Protocol. Durch SAML-Bindings wird der Transport der Nachrichten selbst organisiert, beispielsweise HTTP oder SOAP. Es werden von SAML 6 Bindings definiert. Profile haben bei SAML zwei Bedeutungen. Zum einen versteht man darunter eine Kombination beziehungsweise Einschränkung der zugrunde liegenden Komponenten für einen bestimmten Anwendungsfall. Dazu gehören 5 Single Sign-On und drei einzelne Profile. Zum anderen versteht man unter einem SAML Profil einen definierten Satz von Regeln zur Abbildung von Attributen aus andern Systemen. Beispielsweise wie Attribute aus einem LDAP-System in einer SAML-Assertion als Attribut abgebildet werden können.

SAML-Assertion

 1: <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
 2:   Version="2.0"
 3:   IssueInstant="2005-01-31T12:00:00Z">
 4:   <saml:Issuer Format=urn:oasis:names:SAML:2.0:nameid-format:entity>
 5:     http://idp.example.org
 6:   </saml:Issuer>
 7:   <saml:Subject>
 8:     <saml:NameID
 9:       Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
10:         j.doe@example.com
11:     </saml:NameID>
12:   </saml:Subject>
13:   <saml:Conditions
14:     NotBefore="2005-01-31T12:00:00Z"
15:     NotOnOrAfter="2005-01-31T12:10:00Z">
16:   </saml:Conditions>
17:   <saml:AuthnStatement
18:     AuthnInstant="2005-01-31T12:00:00Z" SessionIndex="67775277772">
19:     <saml:AuthnContext>
20:       <saml:AuthnContextClassRef>
21:         urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
22:       </saml:AuthnContextClassRef>
23:     </saml:AuthnContext>
24:   </saml:AuthnStatement>
25: </saml:Assertion>

Die dargestellte Assertion enthält ein einzelnes Authentication Statement:

• Zeile 1 beginnt die Assertion und enthält die Deklaration des SAML-Assertion Namespace.
• Die Zeilen 2 bis 6 enthalten Metadaten der Assertion: welche Version von SAML benutzt wird, wann die Assertion erstellt wurde und wer sie erstellt hat.
• Die Zeilen 7 bis 12 enthalten Informationen über das Subjekt der Assertion. Es hat einen Name Identifier, dessen Wert j.doe@example.com ist und ein bestimmtes Format besitzt.
• Die Zeilen 13 bis 16 geben die Gültigkeit der Assertion an. Diese Assertion war gültig von 31.01.2005 12:00 mittags UTC bis 10 Minuten später.
• Zeilen 17 bis 24 enthalten das Authentication Statement. Das Subjekt wurde zur angegebenen Zeit durch einen Passwort gesicherten Transport Mechanismus, zum Beispiel Eingabe von Benutzername und Passwort Eingabe in einer SSL- gesicherten Browser-Session, authentifiziert. Außerdem angegeben ist die Zeit zu der die Authentisierung stattgefunden hat.

Attribute Statement

 1: <saml:AttributeStatement>
 2:   <saml:Attribute
 3:      xmlns:x500="urn:oasis:names:tc:SAML:2.0:profiles:attribute:X500"
 4:      NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
 5:      Name="urn:oid:2.5.4.42" 
 6:      FriendlyName="givenName">
 7:      <saml:AttributeValue xsi:type="xs:string"
 8:        x500:Encoding="LDAP">John</saml:AttributeValue>
 9:   </saml:Attribute>
10:   <saml:Attribute 
11:     NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"
12:     Name="LastName">
13:     <saml:AttributeValue
14:       xsi:type="xs:string">Doe</saml:AttributeValue>
15:   </saml:Attribute>
16:   <saml:Attribute
17:     NameFormat="http://smithco.com/attr-formats"
18:     Name="CreditLimit">
19:     xmlns:smithco="http://www.smithco.com/smithco-schema.xsd"
20:     <saml:AttributeValue xsi:type="smithco:type"">
21:       <smithco:amount currency="USD">500.00</smithco:amount>
22:     </saml:AttributeValue>
23:   </saml:Attribute>
24: </saml:AttributeStatement>

Attributsinformationen fallen häufig als Beiprodukt eines Single-Sign-On Vorgangs an oder werden auf explizite Nachfrage bestimmter Attribute übermittelt. SAML Attribute Statements haben den dargestellten Aufbau. Sie können ein oder mehrere Attribute enthalten. Im Beispiel enthält das Attribute Statement drei Attribute beginnend auf Zeile 2, 10 und 16. Alle Attributnamen haben ein Format. Im ersten Fall wird das SAML X.500/LDAP Profile genutzt. Das LDAP Attribut, welches durch OID 2.5.4.42 identifiziert wird, heißt givenName und der Attributwert ist John. Beim zweiten Attribut wird das SAML Basic Attribute Profile genutzt. Das Attribut heißt LastName und enthält den Wert Doe. Das dritte Attribut hat ein Format, das nicht von SAML definiert ist, sondern von SmithCo. Das CreditLimit des Benutzers ist 500 USD. Die Werte der Attribute können einfache Datentypen sein, wie in den ersten beiden Fällen, oder weiter strukturiertes XML wie im dritten Fall.

Ablauf

Im folgenden Beispiel wird das HTTP Redirect Binding zur Übertragung der Authentifikationsanfrage genutzt, sowie das HTTP POST Binding um die SAML Antwort zu verschicken.

1) Der Benutzer versucht auf die Ressource des Service Providers zuzugreifen. Er besitzt keine gültige Logon Session und der aktuelle Zustand wird gespeichert.

2) Der Service Provider sendet einen HTTP Redirect (302 oder 303) an den Browser des Benutzers. Der Header enthält als Ziel den Single Sign-On Service des Identity Providers und zwei query Variablen. Eine davon ist RelayState, welche den lokalen Zustand oder eine Referenz darauf enthält. Die andere ist ein SAMLRequest, welcher einen deflate komprimierten Authentication Request enthält.

3) Vom Identity Provider wird überprüft, ob bereits ein lokaler Sicherheitskontext besteht, welcher die geforderte Authentisierungspolicy erfüllt. Wenn nicht, wird der Benutzer nach Login Daten gefragt.

4) Der Benutzer führt den Login aus.

5) Der Identity Provider erstellt eine SAML Assertion, die den aktuellen Sicherheitskontext des Benutzers repräsentiert. Die Assertion wird signiert und in eine SAML Response eingebettet. Diese wird base64 komprimiert und in ein HTML FORM als hidden form control names SAMLResponse eingebettet. Der RelayState wird als zweites control Element eingebettet.

6) Der Browser führt jetzt eine HTTP POST Anfrage aus mit den entsprechenden in Schritt 5 generierten Daten. Der Service Provider extrahiert den Response Teil und validiert die Signatur der SAML Assertion. Als nächstes wird der Inahlt abgearbeitet und ein lokaler Sicherheitskontext für den Benutzer erstellt. Anschließend wird noch der lokale Zustand, gespeichert in RelayState, wiederhergestellt.

7) Sollte der Benutzer berechtigt sein die Ressource aufzurufen, wird sie übertragen.

Datenschutz und Sicherheit

Auf dem Level der Assertions gibt es wenige Sicherheitsbedenken, da die meisten Probleme während der Kommunikation im Request/Response Protocol auftauchen. Der Empfänger muss natürlich jegliche Gültigkeitsintervalle der Assertions und Beschränkungen bezüglich <OneTimeUse> Elementen einhalten. Eine Problematik sollte jedoch im Hinterkopf behalten werden: Sobald die Assertion einmal abgesendet ist, befindet sie sich außer Kontrolle des Ausstellers. Dies bedeutet, dass der Aussteller keine Kontrolle darüber hat, wie lange eine Assertion im System des Benutzers verweilt oder welchen anderen Parteien die Assertion übermittelt wird. Bei der Ausstellung muss also genau bedacht werden, welche Informationen der Assertion hinzugefügt werden und welche nicht.

Das SAML-Protokoll ist anfällig für Denial of Service Attacken. Das liegt darin begründet, dass die Handhabung eines SAML-Requests eine aufwendige Operation sein kann. Die Nachricht muss geparst werden, üblicherweise durch Aufbau eines DOM-Baums. Es muss eine Datenbank beziehungsweise Assertion Suche durchgeführt werden. Eine Antwort-Nachricht muss konstruiert werden und es müssen möglicherweise mehrere Signierungen vorgenommen werden. Der Aufwand des Anfragen erzeugenden Angreifers ist also weit geringer als die Handhabung der eingehenden Anfragen.

Gegenmaßnahmen beinhalten eine Authentisierung auf einem niedrigeren Level beispielsweise mit HTTP over TLS/SSL und Klient seitigen Zertifikaten mit einer vertrauenswürdigen Zertifikats-Autorität. Eine Zurückverfolgung wäre bereits jetzt möglich. Fügt man noch eine Zugangskontrolle hinzu sind DOS-Attacken nur noch von Insidern möglich. Wird eine signierte Anfrage verlangt, reduziert sich dadurch die Asymmetrie zwischen der Arbeit die vom Nachfragenden und Antwortenden erledigt werden. Während nämlich die Verifikation der Signatur nur einen geringen Teil der Arbeit, die vom Antwortenden erledigt wird, entspricht, stellt sie einen sehr großen Anteil an der zu erledigenden Arbeit des Anfrage-Stellers.

Die Anfälligkeit während des Transports bezüglich Belauschens, Veränderns oder eines Man-in-the-Middle Angriffs unterscheidet sich hinsichtlich des verwendeten Bindings. Die Definition für SOAP ist besonders schwach und enthält hierzu keinerlei Vorschriften. Die Verwendung von HTTP over TLS/SSL, möglicherweise mit beidseitigen Zertifikaten, schließt diese Schwachpunkte aber in allen Bindings weitestgehend aus.

Quellen

• SAML Technical Overview
• SAML Assertions and Protocols
• SAML Bindings
• SAML Profiles
• SAML Security and Privacy Considerations