Im Zusammenhang mit Web-Services gewinnt SAML an Bedeutung, damit Sicherheitsinformationen einheitlich zwischen Anwendungen und Authentifizierungs- sowie Autorisierungs-Servern auszutauschen sind.

Als es nur den Mainframe gab, war das Sicherheitsmanagement noch relativ einfach. Der Anwender setzte sich an ein Terminal, gab Username sowie Passwort ein und erhielt Zugang zur Anwendung – oder auch nicht. Mittlerweile bevölkern verschiedenste Systeme die Backend-Landschaft eines Unternehmens. Außerdem kommunizieren noch alle möglichen Anwendungen miteinander. Mit der Zunahme von Web-Services und der Kommunikation von Anwendungen auch über Unternehmensgrenzen hinweg wächst die Komplexität des Ganzen noch. Aber die Frage lautet immer: Wer darf mit welchen Rechten auf welche Funktionen einer Anwendung zugreifen? Dazu muss sich ein Subjekt, sei es ein User oder ein Programm, zuerst einmal gegenüber einer Authentifizierungs-Instanz identifizieren. In einem zweiten Schritt geht es darum, den Kontext zu bestimmen: Also welche Attribute sind wichtig? Dies kann etwa die Rolle des Subjekts sein, mit der es auf eine bestimmte Ressource zugreifen will. In einem dritten Schritt muss eine Autorisierungsinstanz entscheiden, ob beziehungsweise mit welchen Rechten das Subjekt auf die Ressource zugreifen darf. Mit SAML (Security-Assertion-Markup-Language) entwickelt sich nun ein standardisierter Weg, auf dem Sicherheitsinformationen für Autorisierung und Authentifizierung zwischen Anwendungen beziehungsweise Identitätsmanagement-Systemen auszutauschen sind. Dies kann die Abhängigkeit von einem bestimmten System deutlich verringern. In dem Maße, wie Web-Services weiter an Verbreitung gewinnen, gewinnt SAML auch an Bedeutung. Denn SAML bietet sich als auf XML basierende Sprache an, im Rahmen von WS-Security (Web-Service-Security) Sicherheitsinformationen in den Nachrichtenaustausch von Web-Services einzubetten.

Profi-Workshop Inhalt: Aufbau und Arbeitsweise von SAML, damit Sicherheitsinformationen zwischen Identitätsmanagementsystemen und Anwendungen ausgetauscht werden können.

Voraussetzung: Identitätsmanagement-System und Anwendungen mit SAML-Unterstützung.

Die Standardisierungsorganisation OASIS (Organisation-for-the-Advancement-of-Structured-Information-Standards) entwickelte SAML 1.1 als ein XML-Framework. Eine Version 2.0 wurde im August als Committee-Draft verabschiedet. Zum einen verwendet die Liberty-Alliance-Spezifikation, der Gegenentwurf zu Microsofts Passport-Ansatz, SAML für ein Single-Sign-On im Web. Zum anderen kommt SAML als Authentifizierungs-Dienst in der Web-Service-Security-Spezifikation (WS-Security) zum Einsatz. Weitere Informationen zur Sicherheit von Web-Services finden sich in dem Artikel »Schutz für Web-Diener« der Ausgabe 4/04 der Network Computing auf S.60 ff. Web-Services entwickeln sich derzeit als ein besonders interessanter Bereich für den SAML-Einsatz. Provisioning-Pakete wie Novells »Nsure« oder Computer Associates´ »eTrust Admin« für die Verwaltung von Sicherheitsressourcen unterstützen SAML. Auch Software-Hersteller wie CrossLogix, IBM (Tivoli Systems), Netegrity, Novell, Oblix, RSA Security oder Sun offerieren SAML-Unterstützung in ihren Sicherheitsanwendungen.

Info SAML-Authentication-Assertion

<saml:Assertion

MajorVersion=”1” MinorVersion=”1”

AssertionID=”186CB370-5C81-4716-8F65-F0B4FC4B4A0B”

Issuer=”www.nwc.com”

IssueInstant=”2003-09-18T13:20:00-05:00”>

<saml:Conditions

NotBefore=”2003-09-18T13:20:00-05:00”

NotAfter=”2003-09-18T13:25:00-05:00”>

<saml:AuthenticationStatement

AuthenticationMethod=”password”2)

AuthenticationInstant=”2003-09-18T13:21:00-05:00”>3)

<saml:Subject> 1)

<saml:NameIdentifier

NameQualifier=http://www.nwc.com

Format=”http://www.customformat.com”>

uid=alice

</saml:NameIdentifier>

</saml:Subject>

</saml:AuthenticationStatement

</saml:Assertion>

1) Das Subjekt ist der Anwender, in diesem Beispiel also Alice.

2) Das Attribut gibt die Authentifizierungsmethode an, die verwendet wurde, um die Identität des Anfragenden zu überprüfen. Hier war es eine Passwortabfrage.

3) Das Attribut gibt Auskunft über den Zeitpunkt, an dem das Subjekt authentifiziert wurde: 13:21:00 Uhr am 18. September 2003.

Bestätigung der Identität

SAML arbeitet unabhängig von einer bestimmten Plattform. Es besteht aus Assertions, Protokollen, Bindings und Profilen. Assertions sind Aussagen, die eine Instanz für Identitätsfragen über einen Endanwender macht, sei es Mensch oder Maschine. Eine solche Instanz ist eine vertrauenswürdige Quelle, die Authentifizierungs- und Autorisierungsentscheidungen fällt wie ein Active-Directory. Eine Identitäts-Autorität erstellt eine Assertion als Antwort auf Anfragen wie: »Darf John Smith auf die Human-Resource-Web-Site zugreifen?« Protokolle beschreiben das Frage-Antwort-Spiel mit SAML für Sicherheitsauskünfte. Bindings verknüpfen SAML mit einem Transport-Protokoll. Profile geben Auskunft, wie SAML-Tokens übermittelt werden.

Die Assertion enthält auch Informationen darüber, von welchem Typen die Anfrage war. Wenn ein Anwender beispielsweise um die Erlaubnis nachfragt, auf eine Human-Ressource-Anwendung (HR) zuzugreifen, dann sagt die Assertion außerdem auch aus, ob die Bitte um Zugang vom System angenommen oder abgelehnt wurde. Außerdem gibt die Assertion an, welche Privilegien der Anwender für den Zugriff erhält. Fragt der User um Authentifizierung für das Netzwerk oder eine Anwendung nach, enthält die Assertion die Methode der Authentifizierung sowie Zeit und Datum, wann diese stattfand. Dies hilft der Anwendung zu entscheiden, ob die Methode ausreicht, die der User durchlief. Einige Lösungen wie E-Mail oder E-Commerce-Programme akzeptieren ein Passwort, während andere etwas Stärkeres wie ein Security-Token verlangen werden. Die Anwendung kann eine Assertion annehmen oder ablehnen. SAML kann für die Identitätsüberprüfung Passwörter, Kerberos, Secure-Remote-Passwörter, Hardware-Tokens, Public-Keys, X.509-, SPKI- (Simple-Public-Key-Mechanismen), XKMS- (XML-Key-Management-Specification) oder SSL/TLS-Zertifikate sowie elektronische Unterschriften mit XML verwenden.

Info Arbeitsweise von SAML

1) Ein Anwender bittet um Zugang zu einer Anwendung. Er gibt http://www.example.com/jobposting .html ein.

2) Die Anwendung fragt nach seinem Berechtigungsnachweis (Credentials). Der Nutzer gibt beispielsweise für eine Authentifizierung über Username/Passwort »John Smith« und sein Passwort »h17&v51« ein.

3) Die Anwendung schickt eine Anfrage an den Identitätsmanagementserver für eine SAML-Assertion mit dem Berechtigungsnachweis. Dazu schickt die Anwendung Loginname und Passwort, die es vom Nutzer erhalten hat, in Form eines SAML-Requests an den Server.

4) Der Identitätsmanagementserver fragt den entsprechenden Authentifizierungsserver und berücksichtigt dabei vorkonfigurierte Policies. Die Abfrage erfolgt im eigenen Protokoll des AuthentifizierungsServers. Hier schickt der Identitätsmanagementserver die Anfrage an einen LDAP-Server, um festzustellen, ob John Smith existiert und ob sein Passwort mit dem abgelegten übereinstimmt.

5) Der Identitätsmanagementserver schickt eine SAML-Assertion an die Anwendung zurück. Wenn der LDAP-Server in dem Beispiel bestätigt hat, dass John Smith existiert und sein Passwort korrekt ist, erzeugt der Identitätsmanagementserver eine SAML-Assertion, die die Authentifizierung von John Smith bestätigt.

6) Das weitere Vorgehen hängt nun von der Anwendung ab. Sie kann entweder dem Nutzer den Zugang gewähren, oder sie schickt einen SAML-Request für eine Autorisierung. Dann geht es wieder mit Schritt 4 weiter. In diesem Beispiel wird die Anwendung danach fragen, ob John Smith eine Berechtigung hat, auf »jobposting.html« zuzugreifen.

Eine Assertion kann drei verschiedene Statements enthalten: Authentication-, Attribute- oder Authorization-Decision-Statements. Ein Authentication-Statement versichert, dass das Subjekt durch die angegebene Methode zu diesem Zeitpunkt authentifiziert beziehungsweise nicht authentifiziert wurde. Autorisierungs-Assertions erlauben oder verwehren den Zugang zu bestimmten Ressourcen wie Dateien, Geräten, Web-Seiten, speziellen Datenbankfeldern oder Aktionen wie der Aktualisierung einer Liste mit Telefonnummern. Um etwa den Zugang zu einer Datenbank bis auf Feldebene zu regeln, muss ein Unternehmen zwar einigen Aufwand für Entwicklung und Pflege der umfangreichen Sicherheitsregeln treiben. Aber gesetzliche Vorschriften oder der hohe Schaden bei einer Manipulation erfordern einen solchen Aufwand. Über SAML-Attribute-Assertions kann ein Administrator Usern auf Grund ihrer Rolle in einer Anwendung Zugang zu bestimmten Informationen gewähren.

SAML-Protokolle

Das Format von Anfragen und Antworten definieren die SAML-Protokolle. Aller Austausch von SAML-Informationen basiert auf bestimmten Voraussetzungen wie einer vertrauenswürdigen Beziehung zwischen dem Fragenden (Requestor), der Anwendung, und dem Antwortenden (Responder), etwa einem Identitätsmanagementsystem. Beide Parteien müssen sich auf das gleiche Subjekt beziehen. Daher gibt es beispielsweise nur ein Subjekt mit dem Namen »Bruce« in der Security-Domäne »networkcomputing.de«.

Ein XML-Schema definiert den Aufbau der Requests (Anfragen) und Responses (Antworten). Jede Anfrage und Antwort besitzen einen Standardkopf (Header). Der Name-Space »samlp« beschreibt diesen Protokollaufbau. Der Name-Space »saml« dagegen gibt den Aufbau der Assertions an.

Neben den Basisprotokollen definiert SAML auch Elemente (Artefakte) für die Browser-Umleitung (Redirection) und Single-Sign-On. Ein Artefakt ist ein Pointer auf eine SAML-Assertion, über den die Anwendung die Assertion erhalten kann. Die Größe eines Artifakts beträgt weniger als 64 KByte und ist damit klein.

Info Request und Response

#<samlp: Request

MajorVersion=”1” MinorVersion=”1”

RequestID=”123.456.7” >

<samlp: QUERYTYPE>

…

</samlp: QUERYTYPE>

<samlp: Request>

<samlp: Response

MajorVersion=”1” MinorVersion=”1”

ResponseID=”192.155.11.20.12345”

InResponseTo=”192.155.11.20.12345”

IssueInstant=”2003-5-14T10:00:15Z”>

<samlp:Status>

<samlp:StatusCodeValue=”samlp:Success”/>

</samlp:Status>

<saml: Assertion

MajorVersion=”1” MinorVersion=”0”

AssertionID=”191.101.10.20.12345”

Issuer=”nwcinc.com >

<saml: Conditions

NotBefore=”2003-5-14T10:00:20Z”

NotAfter=”2003-5-14T10:00:50Z”

</saml: Conditions>

<saml: ResponseType>

…

</saml: ResponseType>

<saml: Assertion>

</samlp: Response>

Der QUERYTYPE des Requests (Anfrage) kann »AttributeQuery«, »AuthenticationQuery« oder »AuthorizationDecisionQuery« sein.

Die aktuellen Elemente innerhalb der Abfrage hängen vom Typen ab. Die Response (Antwort) besitzt ein ähnliches Format, wobei der RESPONSETYPE entweder »AuthenticationStatement«, »AuthorizationDecisionStatement« oder »AttributeStatement« ist.

Bindings und Profile

Ein Binding gibt die Methode an, welche die SAML-Anfragen und-Antworten transportiert. Das am häufigsten verwendete Binding oder Transport-Protokoll für SAML ist SOAP (Simple-Object-Access-Protocol) über HTTP. Aber die OASIS arbeitet mit SAMLv2 auch an einem reinen HTTP-Transport für SAML. Verschickt eine Anwendung eine SAML-Anfrage mittels SOAP über HTTP, liegt der Request beziehungsweise die Response im Body der SOAP-Nachricht. Eine SOAP-Nachricht markieren die Tags für den Envelope, in dem wiederum Tags die Bereiche für den Header sowie den Message-Body festlegen. Weitere Elemente als die SAML-Komponene muss der Body nicht enhalten. Kann ein Empfänger eine SAML-Anfrage nicht bearbeiten, muss er einen SOAP-Fehler-Code schicken. Lehnt der Empfänger etwa die Verarbeitung ab, sollte er ein »403 Forbidden« zurückschicken. Wenn es um SAML-spezifische Probleme geht, darf der Empfänger keinen SOAP-Fehler-Codes schicken wie bei einer Ablehnung des Zugangs. HTTP-Proxies dürfen übrigens SAML-Assertions nicht cachen.

Info SAML-Authorization-Decision-Assertion

<saml:Assertion >

MajorVersion=”1” MinorVersion=”1”

AssertionID=”186CB370-4581-4716-8F65-F124FC4B412B”

Issuer=”www.nwc.com”

IssueInstant=”2003-09-18T13:20:00-05:00”>

<saml:Conditions

NotBefore=”2003-09-18T13:20:00-05:00”

NotAfter=”2003-09-18T13:25:00-05:00”/>

<saml:AuthorizationStatement

Decision=”Permit” 2)

Resource=”http://www.nwc.com/article1.html”> 3)

<saml:Subject> 1)

<saml:NameIdentifier

NameQualifier=http://www.nwc.com

Format=”http://www.customformat.com”>

uid=alice

</saml:NameIdentifier>

</saml:Subject>

<saml:Actions

ActionNamespace=”http://www.oasis-open.org/xmlactions/”>

<saml:Action>Read</saml:Action 4)

</saml:Actions

</saml:AuthorizationStatement

</saml:Assertion>

1) Das Tag markiert das Subjekt, das auf die Ressource zugreifen will.

2) Das Attribut gibt die Entscheidung an, welche die Authentifizierungsinstanz gefällt hat.

3) Das Attribut beschreibt die Ressource, auf die das Subjekt, hier Alice, zugreifen will.

4) Das Tag beschreibt die Ressource, auf die das Subjekt zugreifen will und mit welcher Aktion. Hier spricht Alice als Ressource eine Webadresse an, um den Inhalt zu lesen.

Ein SAML-Profil beschreibt als ein Beispiel, wie eine SAML-Assertion einem Aufruf für eine Ressource mitgegeben beziehungsweise diesem entnommen wird. Das Profil gibt etwa den Ort an, an dem die SAML-Assertion innerhalb einer Nachricht liegt. Derzeit existieren ein Profil für WS-Security sowie zwei für den Einsatz mit Web-Browsern. WS-Security beschreibt, grob gesagt, wie WS-Signature und WS-Encryption bei SOAP-Nachrichten anzuwenden sind. Bei einer SOAP liegt die SAML-Assertion innerhalb des WS-Security-Headers, welchen die Tags »<wsse:Security>« und »</wsse:Security>« begrenzen. Der WS-Security-Header wiederum liegt im SOAP-Header.

Für den Web-Browser gibt es zwei Profile: »push« und »pull«. Im Push-Profil schickt der Browser die Formulardaten einschließlich der SAML-Assertion zum Web-Server mittels HTTP-Post. Im Pull-Profil dagegen werden SAML-Artefakte als Teil des URL-Abfrage-Strings übergeben. Ein SAML-Artefakt verweist auf die eigentliche SAML-Assertion. Die große Herausforderung liegt bei dem Austausch der SAML-Assertion mittels Pull. Die Assertion wird an den Abfrage-Teil der URL angehängt. Die meisten Browser beschränken die Länge einer URL. Der Internet-Explorer etwa erlaubt zwei KByte. Einige SAML-Assertions würden damit zu groß sein, dort um Platz zu finden. SAML-Artefakte können dieses Problem umgehen.

Sichere Kommunikation

Für einen sicheren Austausch von SAML-Nachrichten empfiehlt die OASIS HTTP über SSL 3.0 beziehungsweise TSL 1.0. SSL beziehungsweise TSL hilft auch bei der gegenseitigen Authentifizierung der Kommunikatiospartner mittels Client- beziehungsweise Server-Zertifikat. Ein Server muss nach der SAML-Spezifikation Clients mittels X.509-Zertifikaten identifizieren. Eine digitale Signatur nach den XML-Signature-Standards des W3C schützt vor Manipulationen der Nachricht, insbesondere des SAML-Tokens. Die SAML-Spezifikation schränkt den XML-Signature-Einsatz ein wenig ein, damit SAML-Anwendungen nicht die volle XML-Signature-Spezifikation implementieren müssen. Von den Möglichkeiten bei XML-Signature, eine Signature mit einem Dokument zu verbinden, müssen SAML-Assertions und -Protokolle »enveloped signatures« verwenden. SAML sollte dabei »Exclusive Canonicalisation« verwenden. Dadurch können Anwendungen die Signature einer SAML-Nachricht unabhängig von umgebenden XML-Kontext überprüfen.

Gelingt es etwa einem Angreifer etwa den SAML-Artefakt gemeinsam mit der URL zu rekonstruieren, kann er sich als der entsprechende Anwender ausgeben. Um diese Gefahr möglichst gering zu halten, sollte beispielsweise die Gültigkeitszeit, welche die Attribute »NotBefore« und »NotOnAfter« festlegen, möglichst klein sein. Die Empfänger-Site muss die Gültigkeitsperiode der Assertion überprüfen und sie eventuell zurückweisen.

SAML-Konformität

Anwendungen oder Produkte, die SAML-konform sein wollen, müssen angeben, welche Bindings und Profile sie unterstützen. Dazu kommt die Aussage, ob die Lösung für die jeweiligen Bindings als Produzenten, Konsumenten oder beides arbeiten können. Schließlich gehört noch die Auskunft dazu, welche Assertions die Lösung für jedes Binding bereitstellt. Das SOAP-Binding ist dabei Pflicht. Das SAML-Schema enthält Pflicht- und optionale Elemente. Eine Anwendung muss alle Elemente verarbeiten. Optionale Elemente muss sie aber nicht erzeugen können.

Weitere Informationen zu SAML finden sich unter anderen auf den Seiten der OASIS unter www.oasis-open.org/committees/tc_home.php?wg_abbrev=security oder http://xml.coverpages.org/saml.html. [ nwc, wve ]