Web Services entwickeln sich zu einem De-facto-Standard, um Funktionalitäten von Geschäftsanwendungen plattformübergreifend anderen Anwendungen zur Verfügung zu stellen. Neue Anwendungen lassen sich auf Basis solcher Web-Services-Bausteine aufbauen, indem auf existierende Funktionalitäten zurückgegriffen wird. Solche Services können synchron sein (einfaches Request/Response-Schema wie bei Remote Procedure Calls), sie können aber auch asynchron sein (Aufruf und späterer Callback, z.B. bei langlaufenden Workflow Services). Sie können einfach lesende Funktionen implementieren (z.B. Börsenkurse oder Wetterinformationen liefern) oder transaktionalen Charakter haben (z.B. Reisebuchungen). Schon heute lassen sich auf Basis von Web Services Orches-trierungsstandards wie BPEL (Business Process Execution Language) benutzen, um Geschäftsprozesse von Anfang bis Ende abzubilden, auszuführen und zu verwalten. Bei der Verwendung von Web Services im professionellen Umfeld stößt man schnell auf das Thema Sicherheit.
- Wie stellt man sicher, dass niemand die übertragenden Daten liest?
- Wie stellt man nun sicher, dass ein Service Consumer berechtigt ist, bestimmte Funktionen eines Service Providers aufzurufen?
- Wie stellt man sicher, dass Daten auf dem Weg zwischen Consumer und Provider nicht verändert werden?
- Wie lassen sich solche Sicherheitsanforderungen erfüllen, wenn die Web Services aus existierenden Business-Funktionen generiert werden, in denen keine Sicherheitsprüfungen implementiert sind?
- Wie kann die Nutzung von Web Services automatisch geloggt werden?
WS-Security
In der nächsten Stufe bietet OASIS WS-Security als Erweiterung der Basis-Standards SOAP und WSDL die Möglichkeit, den Austausch von SOAP-Nachrichten zwischen dem Service Requester und dem Service Provider auf Ebene der Nachrichten selbst zu verschlüsseln, gegen Veränderungen zu sichern (Integrität) sowie eine gegenseitige Authentifizierung durchzuführen. Basierend auf den W3C-Standards XML Encryption und XML Digital Signatures wird der SOAP Request zunächst signiert, verschlüsselt und, mit einem Authentifizierungs-Token versehen, über die Leitung an den Service-Provider geschickt. Hier wird der Authentifizierungs-Token geprüft, die Nachricht entschlüsselt und die Signatur geprüft, bevor der eigentliche Service-Aufruf erfolgt. Bei der Übertragung der SOAP-Nachricht an den Service-Requester erfolgt die gleiche Prozedur. Der Authentifizierungs-Token kann ein einfacher Username/Password-Token sein oder aber signierte Tokens wie X.509-Zertifikate. Die Tokens werden bei der Kommunikation in die Header der auszutauschenden SOAP-Nachrichten gestellt. Listing 1 zeigt, wie dies bei einem Username-Token aussieht.<?xml version="1.0" encoding="utf-8"?><S11:Envelope xmlns:S11="..."xmlns:wsse="..." xmlns:wsu="..." xmlns:ds="..."><S11:Header><wsse:Security xmlns:wsse="..."><wsse:UsernameToken wsu:Id="Example"><wsse:Username> ... </wsse:Username><wsse:Password Type="..."> ... </wsse:Password><wsse:Nonce EncodingType="..."> ... </wsse:Nonce><wsu:Created> ... </wsu:Created></wsse:UsernameToken></wsse:Security></S11:Header><S11:Body wsu:Id="MsgBody"><tru:getBalance xmlns:tru="http://samplebank.com/ws">65712356</tru:getBalance></S11:Body></S11:Envelope>
Authentifizierung mit SAML
Ein weiterer wichtiger Standard beim Einsatz von Web Services ist die Security Assertion Markup Language SAML. Hierbei wird der Prozess der Prüfung von Authentifizierung (wer ist der Service-Requester?) und Autorisierung (was darf der Service-Requester) nicht dem einzelnen Web Service aufgebürdet, sondern einem zentralen Sicherheitsservice. Das Ergebnis ist ein so genannter optional signierter SAML-Token, der ebenfalls in WS-Security-Aufrufen übertragen werden kann und dem der Service vertrauen kann. Die Idee ist dabei, dass dadurch Sicherheitskontexte von einem aufgerufenen Service auf einen evtl. von diesem aufgerufenen Service "weitergereicht" werden können. SAML-Tokens unterscheiden sich also von Username/Passwort- oder X.509-Tokens dahingehend, dass sie die Authentifizierung bereits enthalten. Eine weitere Anwendung besteht in der Nutzung eines Single-Sign-on-Dienstes als SAML-Security Service. Hat sich beipielsweise der Nutzer einer Portal-Anwendung bereits gegenüber einem Single-Sign-on-Dienst authentifiziert und ruft diese Anwendung einen Web Service auf, wird dem SOAP-Request ein SAML-Token mitgeliefert, der dem empfangenden Service mitteilt, dass der User bereits authentifiziert und autorisiert ist und weitere Prüfungen nicht notwendig sind.Auf Basis dieser Technologien gibt es heute schon Software-Produkte, die Policy-basiert Web Services sichern. Als Beispiel sei hier der Oracle Web Services Manager genannt, der als eine Art Web Services Firewall fungiert.
Policy-basierte Sicherung von Web Services
Die Implementierung der Business-Funktionalitäten wird in den Services von den Sicherheits-Policies getrennt. Dadurch können diese zentral administriert und automatisch allen Services zur Verfügung gestellt werden. Die Web Services selbst müssen nicht angepasst werden, wenn sich diese Policies ändern. Eine solche Policy kann typischerweise beinhalten- Entschlüssele die ankommende Nachricht
- Extrahiere die Anmelde-Daten des Nutzers
- Prüfe die Authentifizierung des Nutzers über ein zentrales Verzeichnis (z.B. Pass- word-Check gegen ein LDAP-Verzeichnis oder Prüfung eines SAML-Tokens, der beispielweise von einem Single Sign-on Server ausgegeben worden ist)
- Prüfe die Autorisierung des Nutzers (darf er die angeforderte Operation des Web Service nutzen?)
- Protokolliere den Service-Aufruf im Logfile
- Leite den Service-Aufruf an den eigentlichen Service weiter, wenn alles okay ist
- Protokolliere andernfalls einen Fehler und gebe einen Fehler als Rückgabenachricht an den Service Requester
Web Services Management Gateway
Mithilfe des Web Services Management Gateway wird ein zentraler Proxy-Service zur Verfügung gestellt, der typischerweise innerhalb einer Demilitarisierten Zone (DMZ) im Unternehmensnetzwerk implementiert wird. Alle Service Requests, die eine besondere Sicherung benötigen, gehen an diesen Proxy-Service und enthalten die Request-Daten für den eigentlichen Service (hier Business-Service genannt) in den Parametern. Die Details dieser Business Services sind nach außen komplett abgeschirmt. Der Proxy-Service gibt nach Abarbeitung der Policies den Request weiter (bzw. gibt einen Fehler zurück). Die Antwort des Business Service wird ebenso nicht direkt an den Requester zurückgegeben, sondern ebenfalls über den Proxy-Service, der gegebenenfalls die Antwort verschlüsselt und signiert. Des Weiteren kann ein Web Services Management Gateway auch genutzt werden, um Protokollanpassungen für Nicht-SOAP-Services vorzunehmen. So kann z.B. eine XML-über-http-Nachricht in einen Java-Messaging-Service-(JMS-)Aufruf umgewandelt werden. Weiterhin können Routing Policies hinterlegt werden, nach denen die Requests an die Business Services weitergeleitet werden. Die Policies werden über ein zentrales, browserbasiertes Tool administriert, in einer datenbankbasierten Registry gespeichert und von dort an die Proxy-Services per Push weitergeleitet.Web Services Agents
Alternativ zu den Gateways gibt es auch die Möglichkeit, die Policies über so genannte Web Services Agents zu implementieren. Auch hier werden Policies zentral verwaltet und per Push an die Services verteilt. Diese Policies werden aber dezentral in den Prozessräumen der Business-Services-Host-Rechner durch einen zwischen dem SOAP Interface und den Business Services geschalteten Software Agent selbst durchgeführt. So kann beispielsweise die Verschlüsselung und Integrität der Kommunikation bis zum Service-Endpunkt gewahrt werden. Der Nachteil ist, dass keine Transformation oder Rerouting stattfinden kann.
Überwachung der Web-Services-Aufrufe
Die Überwachung der Nutzung von Web Services wird durch Logging und Auditing ermöglicht, die von Gateways und Agents gewährleistet werden. So lassen sich z.B. Versuche, nichtautorisiert Dienste zu nutzen, schnell erkennen. Des Weiteren lassen sich technische Performance-Statistiken auswerten (wie z.B. die durchschnittlichen Ausfall- oder Antwortzeiten).Zusammenfassung
Web Services sind auf dem besten Weg, unternehmensinterne Business-Funktionen als Dienst zur Verfügung zu stellen und herkömmliche monolithische Anwendungen abzulösen. Das Thema Sicherheit ist bisher ein Stolperstein auf dem Weg dorthin gewesen. Hier erlauben Standards wie WS-Security die Kommunikation mit den Services im Hinblick auf Verschlüsselung, gegenseitige Authentizität der Beteiligten sowie Integrität der Nachrichten. Zusätzlich erlaubt SAML die Authentifizierung gegenüber solcher Services im Rahmen von Single-Sign-on-Verfahren. Web Services Manager können heute bereits diese Standards implementieren und setzen zentral verwaltbare Security-Policies als eine Art Service-Firewall durch (entweder als zentraler Proxy-Service oder aber als Agents auf den Business-Services-Host-Rechnern selbst) und protokollieren die Benutzung dieser Services. Diese Technologien stellen einen wichtigen Schritt dar, um auch Unternehmen in sicherheitssensiblen Branchen, wie z.B. dem Finanzwesen oder dem öffentlichen Dienst, die Nutzung von serviceorientierten Architekturen zu ermöglichen.
Dr. Ingo Laue hat als System Engineer und Consultant bei EDS und Oracle in vielen Individualsoftware-Entwicklungsprojekten gearbeitet. Er ist heute als System Consultant bei Oracle auf die Themen Integration und SOA fokussiert.
