Federation-Technologien im Detail
Der Grundansatz der Sicherheit für Web Services
Das Ziel von Web Services ist die Interoperabilität zwischen verschiedenen Systemen in heterogenen Umgebungen. Wie häufig bei der Entwicklung von Standards spielte das Thema Sicherheit bei der Entwicklung zunächst eine untergeordnete Rolle. Entsprechend findet man schon längere Zeit verschiedene Web Service-Standards, während die dazu gehörenden Sicherheitsstandards noch relativ jung sind.
Die Herausforderung dabei ist, dass sehr unterschiedliche Sicherheitsmechanismen erforderlich sind, da Web Services in unterschiedlichen Szenarien genutzt werden können. Die Anforderungen innerhalb von Unternehmen unterscheiden sich deutlich von denen, die es im B2BUmfeld oder bei Web Service Angeboten von Dienstleistern gibt. Entsprechend umfassend sind auch die Sicherheitsstandards.
Die Notwendigkeit für spezielle Sicherheitsstandards für Web Services entsteht vor allem daraus, dass mit End-to-End-Security gearbeitet werden muss. Zwischen dem anfordernden System (Requestor) und dem Zielsystem, also dem Web Service, können sich noch andere Systeme befinden. Ein Ansatz wie SSL, der sich jeweils nur auf die Verbindung zwischen zwei Systemen bezieht, ist daher nicht ausreichend. Es ist eine Lösung erforderlich, die Informationen über den gesamten Weg sichert – was in der Regel über die
erschlüsselung der Informationen erfolgt.
Innerhalb des Web Service-Modells kann ein Web Service bei eingehenden Nachrichten bestimmte Claims erzwingen. Diese müssen vom Requestor geliefert werden. Letzterer benötigt dafür wiederum ein Security-Token, um die Echtheit der Claims zu bestätigen und teilweise auch deshalb, weil die angeforderten Claims Informationen beinhalten, die in den Security-Tokens enthalten sind. Diese Security-Tokens müssen bei einem STS (Security Token Service) angefordert werden (Bild 1).
Dieses Grundmodell der Sicherheit von Web Services arbeitet mit einem STS, der sowohl vom Requestor als auch vom Web Service akzeptiert wird. Hier wird bereits deutlich, dass sich die Erfordernis für Identity Federation stellt, sobald die beiden Systeme nicht mit dem gleichen STS arbeiten. In diesem Fall ist eine wie auch immer geartete Umsetzung der erstellten Security-Tokens erforderlich.
Entsprechend vielschichtig gestalten sich auch die Web Service-Standards im Bereich der Sicherheit (Bild 2). Im Vergleich zur Abbildung sind inzwischen einige der Standards auf höherer Ebene Realität geworden, insbesondere WS-Policy, WS-Trust und WS-Federation. An anderen wie WS-Privacy wird aber noch intensiv gearbeitet.
Der Zusammenhang der Standards
WS-Security als der grundlegende Standard hat das Ziel, eine quality of protection zu liefern, indem die übertragenen Nachrichten gesichert werden. WS-Security wird für viele Bereiche benötigt und spielt beispielsweise auch im Kontext der Liberty-Standards eine Rolle, weil es um die generelle Frage geht, wie man Web Services absichern kann. Daher stellt WS-Security einen allgemein verwendbaren Ansatz für die Zuordnung von Security-Tokens zu Nachrichten auf SOAP-Ebene bereit. Der Ansatz ist erweiterbar und kann beispielsweise zusätzliche Token-Formate unterstützen.
WS-Security ist in jedem Fall erforderlich, wenn in sicherer Weise mit Web Services gearbeitet werden soll. Und da bei der Federation Identitätsinformationen über Web Services übertragen werden, ist der Mechanismus dafür unverzichtbar.
Die beiden Standards WS-Policy und WS-Trust setzen darauf auf. Die Ebene, auf der sich diese Standards befinden, wird auch als Policy Layer bezeichnet, weil hier Richtlinien für die Nutzung der WS-Security von Standards und Anwendungen auf höherer Ebene wie eben WS-Federation definiert werden. WS-Trust definiert, einfach gesagt, wer wem unter welchen Bedingungen vertraut.
WS-Federation benötigt nun wiederum die Standards auf der darunter liegenden Ebene, also WS-Security als Basis und WS-Policy sowie WSTrust für die Vereinbarung des Zusammenspiels zwischen den beteiligten Komponenten. WS-Privacy wird zukünftig eine größere Rolle spielen, weil damit gesteuert wird, wer welche Identitätsinformationen sehen darf. Das ist in komplexeren Federation-Szenarien und insbesondere im B2C-Umfeld unverzichtbar. Allerdings ist hier noch einiges an Standardisierungs- und Implementierungsarbeit erforderlich.