SAML: Das XML-Framework für SSO und Co. im Überblick

SAML (Security Assertion Markup Language) ist ein quelloffenes XML-Framework, das den Austausch von Authentifizierungs- und Autorisierungsinformationen ermöglicht. Die einzelnen SAML-Komponenten, zu denen unter anderem eine zentrale Benutzerdatenbank und sechs verschiedene Protokolle zählen, stellen alle relevanten Funktionen zur Beschreibung und Übertragung von Sicherheitsfunktionen zur Verfügung – weshalb SAML als hervorragende Komplettlösung für das Federated Identity Management (FIM) gilt.

Security Assertion Markup Language, kurz SAML, ist ein quelloffenes Framework auf XML-Basis zum Austauschen von Authentifizierungs- und Autorisierungsinformationen. Es wurde ab 2001 vom Security Services Technical Committee des OASIS-Konsortiums (Organisation for the Advancement of Structured Information Standards) entwickelt und im November 2002 in einer ersten Version (SAML v1.0) veröffentlicht. Im Laufe der Zeit hat das Projektteam diverse Anpassungen vorgenommen, die in den überarbeiteten Versionen SAML 2.0 und 2.1 (auch 1.1) wiederzufinden sind. Der SAML-Standard enthält mehrere Komponenten, die allerelevanten Funktionen zur Beschreibung und Übertragung sicherheitsbezogener Informationen bereitstellen. Damit bildet SAML die optimale Grundlage fürs Federated Identity Management (FIM).

SAML kann u. a. dazu verwendet werden, Aussagen über die Eigenschaften sowie die Berechtigungen eines Benutzers gegenüber anderen Benutzern bzw. Partnerunternehmen, vor allem aber gegenüber Anwendungen zu machen (letztere werden im SAML-Konzept auch als Service-Provider bezeichnet). Hierfür greift der sogenannte Identity-Provider (zentrale Benutzerdatenbank), der entsprechende Nutzerinformationen speichert, auf Assertionsim XML-Format zurück. Weitere Komponenten einer auf dem SAML-Standard basierenden Verifizierungsumgebung sind sechs verschiedene Protokolle sowie Bindings und Profile.

Eine SAML-Assertion kann eine oder mehrere Aussagen über die Eigenschaften (Identität, Attribute)und die Berechtigungen eines Benutzers enthalten. Sie wird durch den jeweiligen Identity-Provider, also die verantwortliche Benutzerdatenbank, erstellt, wobei XML als Auszeichnungssprache zum Einsatz kommt. Jede Assertion erhält zudem eine digitale Signatur, die zunächst durch den zugreifenden Service-Provider, also die jeweilige Anwendung, geprüft und verifiziert werden muss. Auf diese Weise ist die Integrität und Authentizität der Assertion gewährleistet, die man in ihrer signierten Form auch als SAML-Token bezeichnet. Nach erfolgreicher Verifizierung analysiert der Service-Provider den eigentlichen Inhalt und trifft in der Folge eine Entscheidung, ob und welchen Zugriff er dem Benutzer gewährt.

Folgende drei Typen von Aussagen in Assertions sind im SAML-2.0-Standard spezifiziert:

• Authentication Statements: Über Authentication Statements informiert der Identity-Provider die Anwendung darüber, dass der Benutzer authentifiziert wurde. Ferner liefert dieser Aussagentyp in einer Assertion auch Informationen darüber, wann die Authentifizierung stattfand und welche Methode hierfür zur Anwendung kam.
• Attribute Statements: Bei Attribute Statements handelt es sich um Attribute, die mit dem jeweiligen Benutzer verknüpft sind und so der Anwendung über das entsprechende SAML-Token mitgeteilt werden können.
• Authorization Decision Statements: Wenn Authorization Decision Statements in einer SAML-Assertion enthalten sind, hat der jeweilige Benutzer entweder Zugriff auf spezifische Ressourcen erhalten oder ihm wurde der Zugriff auf spezifische Ressourcen verweigert.

Die SAML 2.0-Spezifikation definiert eine Reihe von Abfrage-/Antwort-Protokollen, die es der Anwendung beispielsweise ermöglichen, eine Assertion anzufordern bzw. abzufragen oder einen Benutzer aufzufordern, sich zu authentifizieren. Im Detail handelt es sich dabei um folgende Protokolle:

• Authentication Request Protocol: Das Authentication Request Protocol definiert Nachrichten vom Typ <AuthnRequest>, die benötigt werden, um Assertions mit Authentication Statements zu einem ausgewählten Benutzer abzufragen. Auf Basis dieses Protokolls gelangen die Informationen also von der Datenbank zum Service-Provider, wobei für gewöhnlich das weit verbreitete SAML 2.0 Web Browser SSO Profile (mehr dazu im Abschnitt „Profile“) zum Einsatz kommt.
   
• Assertion Query and Request Protocol: Für Abfragen, mit denen existierende SAML-Assertions im Allgemeinen abgerufen werden können, enthält das Framework das Assertion Query and Request Protocol. Die Abfrage der Assertions kann dabei auf Basis verschiedener Parameter wie beispielsweise der enthaltenen Aussagetypen erfolgen.
   
• Single Logout Protocol: Das Single Logout Protocol definiert Abfragen, die eine nahezu gleichzeitige Abmeldung von allen aktiven Sitzungen eines Benutzers initiieren. Solche Nachrichten können sowohl der Benutzer selbst als auch Identity- oder Service-Provider senden. Letzteres ist vor allem dann denkbar, wenn eine Benutzersitzung abgelaufen ist.
   
• Artifact Resolution Protocol: Sollen SAML-Nachrichten separat über einen sicheren Kanal oder in einer ressourcensparenden Größe transportiert werden, kommt das Artifact Resolution Protocol zum Einsatz. Es ermöglicht den Versand von Referenzen auf Assertions, die auch als Artefakte bezeichnet werden und wesentlich kleiner als die eigentliche Nachricht sind. Das Protokoll erlaubt außerdem, diese Referenzen aufzulösen, um die Originalnachricht zu erhalten.
   
• Name Identifier Management Protocol: Dieses Protokoll stellt Mittel zur Verfügung, um den Namenswert bzw. das -format einer Benutzeridentität zu verändern. Verfasser des Requests kann entweder der Service- oder der Identity-Provider sein. Ferner lassen sich mit dem Name Identifier Management Protocol entsprechende Verknüpfungen zwischen Service- und Identity-Provider entfernen, die für die Authentifizierung der ursprünglichen Benutzeridentität erzeugt wurden.
   
• Name Identifier Mapping Protocol: Das Name Identifier Mapping Protocol definiert Abfrage- und Antwortnachrichten für die Kommunikation zwischen zwei Service-Providern. Auf Basis dieses Nachrichtentyps kann eine Anwendung beim Identity-Provider einen Identifier für einen Benutzer abfragen, um auf eine andere Anwendung zugreifen zu können.

Mappings – also Umwandlungen – des SAML-Nachrichtenaustauschs in Standard-Messaging- oder Kommunikationsprotokolle werden als SAML-Protokoll-Bindings oder auch einfach nur Bindings bezeichnet. So definiert das SOAP Binding beispielsweise, wie sich SAML-Nachrichten innerhalb von SOAP-Umgebungen austauschen lassen, während das HTTP Redirect Binding festlegt, wie SAML-Protokoll-Nachrichten über das HTTP-Weiterleitungsverfahren transportiert werden können. Weitere bereits im SAML-2.0-Standard vordefinierte Bindings sind:

• Reverse SOAP Binding
• HTTP POST Binding
• HTTP Artifact Binding
• SAML URI Binding

Als allgemeiner Standard zeichnet sich SAML durch seine Flexibilität aus, die das Framework für zahlreiche Einsatzszenarien qualifiziert. Damit bestimmte Anwendungen die Verwendung von SAML unterstützen, gilt es allerdings, diese Flexibilität teilweise einzuschränken. Hierfür kommen sogenannte Profile zum Einsatz, die gewählte Assertions, Protokolle und Bindings für spezifische Anwendungsfälle bündeln. Eines der am häufigsten verwendeten Profile ist das oben erwähnte SAML 2.0 Web Browser SSO Profile, das den Rahmen zur Realisierung einer SAML-SSO-Authentifizierung spezifiziert. So enthält es alle entscheidenden Komponenten, um die Kommunikation von SAML-Authentifizierungszusicherungen zwischen Identity- und Service-Provider zu definieren, die für die Einmalanmeldung über einen beliebigen Webbrowser notwendig ist. Ferner liefert das Framework folgende weiteren Profile mit:

• Enhanced Client and Proxy (ECP) Profile
• Identity Provider Discovery Profile
• Single Logout Profile
• Name Identifier Management Profile
• Artifact Resolution Profile
• Assertion Query/Request Profile
• Name Identifier Mapping Profile

Mehr als 24 Unternehmen und Organisationen waren an der Konzeptionierung und Erarbeitung von SAML 2.0 beteiligt, bevor die Version im März 2005 als offizieller Nachfolger von SAML 1.0 bzw. 1.1 veröffentlicht werden konnte. Zusätzlich zu zahlreichen Verbesserungen vorhandener Features erhielt das Framework dabei auch komplett neue Features, die aus dem Liberty Alliance Identity Federation Framework (ID-FF) 1.2 und aus der von Internet2 entwickelten Shibboleth-Architektur übernommen wurden.

Die folgende Auflistung zeigt einige der wichtigsten Anpassungen, die das Framework im zweiten „großen“ Release („major release“) erhalten hat:

• Entfernung einiger veralteter Elemente wie <AuthorityBinding> oder <RespondWith> sowie des veralteten Identifier-Formats
• Implementierung von XML-Signatur und XML-Verschlüsselung (nach W3C-Standard)
• Austausch des AssertionID-Attributs durch ein allgemeines XML-ID-Attribut
• Einführung von Session-Management zur Unterstützung automatischer Abmeldungen von allen Anwendungen (beispielsweise bei langer Abwesenheit)
• Anpassung der Metadaten, um den Einsatz von SAML zu vereinfachen (u. a. sind nun auch involvierte Instanzen wie der Identity-Provider und die Service-Provider in den Metadaten ausgezeichnet)
• Implementierung von Mechanismen, die es den Providern ermöglichen, Privatsphäre-Richtlinien und -Einstellungen zu kommunizieren
• verbesserte Unterstützung mobiler Geräte
• Implementierung der bereits aufgezählten Protokolle (in SAML 1.0 und 1.1 existierte nur das Assertion Query and Request Protocol)
• Optimierung der Profile (z. B. Zusammenführung der Profile „Browser/Artifact“ und „Browser/Post“ im „SAML 2.0 Web Browser SSO Profile“)

Eine detaillierte Auflistung der Unterschiede zwischen SAML 2.0 und SAML 1.1 liefert die SAML-Community-Seite saml.xml.org.

Das Einsatzfeld des SAML-Frameworks ist schnell definiert: Mit dem entsprechenden Know-how lässt sich eine zentrale Authentifizierungsinstanz auf Basis der Auszeichnungssprache realisieren, die sich durch Effizienz und einen hohen Sicherheitsstandard auszeichnet. Letzteres ist insbesondere darauf zurückzuführen, dass die einzelnen Anwendungen keinerlei Benutzerdaten speichern oder synchronisieren müssen, was die Zahl möglicher Sicherheitslecks erheblich minimiert. Der Hauptfokus des Frameworks liegt dabei darauf, diesen hohen Sicherheitslevel mit der bestmöglichen Benutzerfreundlichkeit zu verknüpfen, weshalb es dank entsprechender Protokolle und Nachrichtenformate auch den bereits mehrfach genannten Single Sign-on unterstützt.

Das SAML-SSO-Verfahren, das die Nutzung verschiedener Anwendungen auf Basis einer einzigen Anmeldung ermöglicht, ist dabei nicht nur bei unternehmensinternen Applikationsprozessen gefragt: Die praktische Einmalanmeldung ist heute in den Konzepten diverser Webservices verankert – insbesondere im Onlinebanking und bei mobilen Apps. Häufig bekommt der Benutzer gar nicht mehr mit, dass er es bei der Nutzung solcher Dienste mit mehreren verschiedenen Anwendungen zu tun hat. So wird ein Kunde, der sich einmalig über die Website seiner Bank einloggt, mit großer Wahrscheinlichkeit auf mehr als ein Backend-System zugreifen, wenn er beispielsweise nacheinander Sparbuch, Depot und Kreditkartenkonto öffnet. Dank der SAML-Technologie erscheint es ihm allerdings, als ob er lediglich ein einziges Programm bedient.