Wenn über Sicherheitsstandards für Web-Services und Service-orientierte Architekturen (SOAs) geredet wird, steht häufig die Spezifikation WS-Security (WSS) im Mittelpunkt der Diskussion. Das Bild ist jedoch weitaus komplexer, denn WSS basiert auf zwei anderen Standards und hat zudem weitere hervorgebracht. Darüber hinaus werden derzeit zahlreiche andere sicherheitsorientierte Normen aktiv (oder weniger aktiv) entwickelt, die auf dem WSS-Basiswerk aufbauen und bestimmte zweitrangige Notwendigkeiten adressieren. Um welche Standards geht es dabei? Sind sie wichtig? Und, falls ja: Wann sollten sie eingesetzt werden?

WSS zielt auf drei wesentliche Sicherheitsanforderungen: die Integrität, die Vertraulichkeit und die Authentifizierung von Nachrichten. In Bezug auf die Integrität - also die Gewährleistung für den Empfänger, dass die Nachricht bei der Übertragung nicht verändert wurde und auch von der angegebenen Quelle stammt - baut WSS auf den Standard XML Digital Signature (XML-DSig) des World Wide Web Consortium (W3C). Um für Vertraulichkeit zu sorgen - sprich die Daten zu verschlüsseln -, enthält WSS die Spezifikation XML Encryption des W3C. Die WSS-Spezifikation beschreibt dabei nur, wie diese Spezifikationen innerhalb eines SOAP-Envelopes zu implementieren sind. Die Empfindlichkeit von XML-DSig erfordert jedoch, dass WSS um zusätzliche Bedingungen und Verarbeitungsinstruktionen erweitert wird.

In gewissem Sinne enthält WSS keine Authentifizierung. Die Authentifizierung ist eine Aktion des Nachrichtenempfängers, mit deren Hilfe er vom Nachrichten-Ersteller gesendete Behauptungen (Claims) überprüft. WSS sorgt allerdings für eine Vielzahl von Mechanismen zur Präsentation dieser Claims in Form integrierter oder referenzierter Security-Token, wobei diese Zeichen jedoch auch "selbst-authentifizierend" sein können, wenn sie beispielsweise mit einem dem Empfänger bekannten Schlüssel chiffriert sind. Die Authentifizierung liegt allerdings immer noch in der Verantwortung des End-Services beziehungsweise des Dienstevermittlers.

Die Token-Wahl

Es gibt zwei Arten von Security-Tokens: XML-Token und binäre Token. Die XML-Token umfassen das in WSS beschriebene Username-Token sowie derzeit auch jenes entsprechend der Security Assertion Markup Language (SAML) und Rights Expression Language (REL). Zu den binären Token zählen gegenwärtig X.509-Zertifikate und Kerberos-Tickets. WSS enthält bestimmte Profile, die beschreiben, wie diese Token in den WSS-Security-Header einer SOAP-Nachricht zu integrieren sind. Die ausgereiftesten und am häufigsten eingesetzten Profile sind das Username-Token und X.509-Zertifikate. Es gibt nur wenige Implementierungen von SAML-Token (in der Regel bruchstückhaft) und kaum Implementierungen, die Kerberos- und REL-Token unterstützen.

Vorsicht bei der Implementierung

Anwender sollten bei der Entscheidung zwischen Username-Tokens und X.509-Zertifikaten berücksichtigen, dass die Verwendung von Username-Tokens möglicherweise die Speicherung von Passwörtern im Klartext erfordert - eine außerordentlich schlechte Praxis. Dieses Problem lässt sich zwar umgehen, erfordert aber eine enge Synchronisation von Clients und Servern (und möglichen Zwischenstellen) - eine Option, die nicht immer sinnvoll ist. Unabhängig davon, welche Identitäts-Token verwendet werden, ist WSS nicht besonders gut in der Entdeckung und Abwehr so genannter Replay-Attacken (Hackerangriffe durch erneutes Senden aufgezeichneter Zugangsprozeduren). Ein angemessener Schutz gegen derartige Angriffe setzt voraus, dass der Client, der solche Nachrichten annimmt, die vom Server vorgeschriebenen besten Praktiken befolgt.

Aktuell ähnelt WSS einer "XMLifizierung" von SSL (Secure Sockets Layer). Beide Techniken bieten Verschlüsselung und digitale Signaturen und ermöglichen ein Weiterreichen der Identität. Der kleine Unterschied zwischen den beiden besteht darin, dass der SSL-Handshake eine Möglichkeit enthält, einen symmetrischen Schlüssel zwischen den kommunizierenden Parteien festzulegen. Diese (auch Session Keys genannt) sind beliebter als asymmetrische Schlüssel (oder Public Keys), weil symmetrische Krypto-Algorithmen wesentlich leistungsfähiger sind. Allerdings erfolgt beim Versenden von SOAP-Nachrichten kein Handshake, weshalb alle Verschlüsselungsfunktionen die langsameren Public-Key-Algorithmen verwenden müssen. Das ist eines der Probleme, das WS-SecureConversation lösen wird.

Entwicklungsarbeit

Obwohl sich WS-SecureConversation (WS-SC) noch in der Entwicklung befindet, existieren bereits einige Implementierungen, unter anderem von Microsoft, IBM und Bea. Mit WS-SC können SOAP-Clients und -Services eine Sicherheitsumgebung aufbauen, die mehrere Nachrichtenaustauschprozesse umfasst. So ermöglicht WS-SC nicht nur die Verwendung abgeleiteter Session-Keys, sondern eliminiert auch die Notwendigkeit, Nachrichten über mehrere Austauschstationen erneut zu authentifizieren.

WS-SecureConversation funktioniert bereits, wenn nur ein Client und ein Service an der Konversation beteiligt sind. Durch zusätzliche Aufnahme einer dritten Partei - eines Security Token Service - wird die Funktion aber noch verbessert. Ein Security Token Service ist ein Web-Service, der die WS-Trust Spezifikation umsetzt. WS-Trust definiert ein Request-Response-Protokoll für die Ausgabe von Security-Tokens (X.509 Zertifikate, Kerberos-Tickets, SAML-Token und so weiter). Genauer gesagt erfüllt ein Token-Service drei Funktionen: Er kann einen Token-Typ gegen einen Token austauschen, der für den eigentlichen Web-Service akzeptabel ist (der Endpunkt-Service muss dem Security Token Service natürlich vertrauen). Er kann neue Tokens herausgeben, die eine vom Client ausgehende Behauptung unterstützen (der Client behauptet beispielsweise, "Bill aus der Buchhaltung" zu sein. Der Token-Service überprüft diese Behauptung und gibt ein signiertes Token heraus, mit dem diese Behauptung verifiziert wird). Zudem kann er Tokens für einen Endpunkt-Service bestätigen.

PKI lässt grüßen

In vielen Aspekten ähnelt WS-Trust dem Kerberos Key Distribution Center oder einer vollständigen PKI-Implementierung. Es finden sich aber auch Ähnlichkeiten und Rivalitäten zu XKMS des W3C sowie dem Abschnitt drei der SAML-Spezifikation. In einer Web-Service-Umgebung ist WS-Trust jedoch die führende Spezifikation zur Beschreibung eines Token-Verteilungsdienstes. Ähnlich wie bei WS-SecureConversation wird derzeit noch aktiv an WS-Trust gearbeitet, es stehen aber bereits erste Implementierungen zur Verfügung.

Bei der Verwendung von WSS und verwandten Spezifikationen ist es von Vorteil, wenn die Sicherheitsanforderungen gegenüber Client-Entwicklern und Client-Runtimes eines Dienstes in maschinenlesbarer Form ausgedrückt werden können. Leider verfügt die Web Services Description Language (WSDL) über keinen Mechanismus, der dies direkt ermöglicht. Stattdessen müssen Entwickler das WS-Policy-Framework verwenden, um die Sicherheitsparameter für einen Service auszudrücken.

Alles definiert

WS-Policy definiert eine erweiterbare Mehrzweckstruktur zur Beschreibung und zum Austausch von Informationen über die Einschränkungen und Möglichkeiten eines Web-Service, also Richtlinien. Letztere werden in domain-spezifischen Policy Assertion Languages (PALs) definiert, innerhalb der Security-Domain mit WS-SecurityPolicy. Serviceentwickler nutzen WS-SecurityPolicy zur Beschreibung der Authentifizierungs-, Verschlüsselungs-, Integritäts- und sonstigen Sicherheitsanforderungen der Dienste, die sie erzeugen. Ein weiterer Bestandteil des WS-Policy-Frameworks - WS-Policy Attachment - beschreibt Mechanismen, um diese Richtlinien mit einem Service zu verknüpfen (entweder über WSDL oder UDDI). Idealerweise nutzen Client-Runtimes WS-MetadataExchange, um kompatibler Verträge dynamisch zu erkennen und zu auszuhandeln.

Standardfragen

Wie so viele andere Web-Service-Framework- (WSF-)Spezifikationen befindet sich WS-Policy noch in der Entwicklung. WS-Policy und WS-PolicyAttachment sind vergleichsweise reife Standards, von denen es Implementierungen gibt. Das trifft auch auf WS-SecurityPolicy zu, während WS-MetadataExchange noch hinterherhinkt.

Eine letzte erwähnenswerte Spezifikation ist WS-Federation. Der ursprüngliche Zweck dieser Spezifikation bestand darin, verschiedene Security-Domains aktiv miteinander zu verbinden. Die Arbeiten an dieser Spezifikation wurden jedoch eingestellt, so dass WS-Federation mehr oder weniger gestorben ist.

Aufgrund der starken Ähnlichkeit der WS-Security-Spezifikationen mit bestehenden Sicherheitsprotokollen stellt sich natürlich die Frage: Ist es von Vorteil, Nachrichten mit WSS und nicht mit SSL zu schützen? Die Antwort lautet: Ja. Jede pragmatisch konzipierte Sicherheitsarchitektur wird allerdings beide Techniken verwenden.

WSS oder SSL?

Der grundlegende Unterschied zwischen WSS und SSL besteht darin, dass SSL ein übertragungsorientiertes Sicherheitsprotokoll ist, das die Punkt-zu-Punkt-Kommunikation schützen kann. WSS ist hingegen ein nachrichtenorientiertes Sicherheitsprotokoll, das eine Nachricht vom Sender bis zum Empfänger schützen kann, auch über Vermittlerstellen hinweg. Der Vorteil einer nachrichtenorientierten Sicherheitsfunktion wird besonders deutlich, wenn es um die Komplexität einer verteilten SOA geht. In einem Web-Service-Umfeld ist es unter Umständen nicht möglich, den Zugang auf einen einzigen Punkt zu beschränken. Dienste und Clients werden in unterschiedlichen Programmiersprachen entwickelt und auf verschiedenen Plattformen benutzt. Die Nachrichten wiederum passieren aller Wahrscheinlichkeit nach Zwischenstationen, die eine Nachricht in irgendeiner Form umschreiben können. Solche Szenarien begrenzen die Wirksamkeit übertragungsorientierter Sicherheitsfunktionen.

Derzeit werden Web-Services jedoch häufig verwendet, um eine einfache Punkt-zu-Punkt-Verbindung zwischen Anwendungen zu schaffen. In einem solchen Fall reicht SSL aus, um die Sicherheitsanforderungen eines Unternehmens zu erfüllen (und alle Web-Service-Plattformen unterstützen SSL - zumindest über HTTP). Wenn sich ein Unternehmen jedoch vergrößert und versucht, von der zentralisierten, richtlinien-orientierten Sicherheitsumgebung zu profitieren, die Web-Services ermöglichen, lassen sich diese SSL-basierenden Anwendungen zu WSS migrieren. Anwender sollten beachten, dass WSS reichlich Spielraum für Kompatibilitätsprobleme bietet. Um derlei Ungemach zu vermeiden, sollten Unternehmen sich an die Empfehlungen halten, die das Basic Security Profile der Web Services Interoperability Organization (WS-I BSP) enthält. Außerdem sollte jede Organisation dafür sorgen, dass ihre Web-Service-Plattformen und ihre sicherheitsrelevanten Vermittlungsstellen ebenfalls in vollem Umfang WS-I BSP unterstützen. (ave)