Sichere Web Services unter J2EE

Transkript

1

2 Patrick Schmitt Sichere Web Services unter J2EE Absicherung von Web Services mit WS-Security January 12, 2004 Fachhochschule Trier Betreuung: Prof.Dr.-Ing.DamianWeber Dr. Bernd Kuhlmann, BGS AG, Mainz

3 Erklärung Hiermit erkläre ich, dass ich die nachfolgende Arbeit selbstständig und ohne fremde Hilfe angefertigt habe. Dabei wurden keine anderen Hilfsmittel, als die im beigefügten Verzeichnis angegeben, verwendet. Patrick Schmitt (927151)

4 In den vergangenen Jahren entwickelten sich Web Services von einem Megatrend hin zu einer in vielen Unternehmen produktiv eingesetzten Technologie. Waren die ersten Implementierungen wie bei allen neuen Technologien noch überschaubar, so erreichen aktuelle Projekte leicht den Umfang einiger Millionen Euro und sind damit durchaus als unternehmenskritisch einzustufen. Einhergehend mit der steigenden Bedeutung von Web Services wurde auch der Ruf nach äquivalenten Sicherheitsstandards laut. So äußerten laut einer Studie von Cap Gemini Ernst & Young [1] 60 Prozent der befragten IT-Direktoren Befürchtungen über entstehende Sicherheitslücken durch den Einsatz der neuen Technologie. Die daraus entstandenen Standards und Protokolle zur Absicherung von Web Services sollen im folgenden betrachtet werden, anschließend wird eine Implementierung vorgestellt, die es ermöglicht, Web Services dem WS-Security-Standard konform abzusichern.

5 Inhaltsverzeichnis 1 Web Services - eine kurze Einführung WassindWebServices? ArchitekturvonWebServices Vergleich zwischen Sun ONE und Microsoft.NET SunONE Microsoft.NET Fazit Vor-undNachteilevonWebServices Standards im Bereich Web Services XML-ExtensibleMarkupLanguage Status Merkmale SOAP - Simple Object Access Protocol Status Ziele Merkmale Implementierungen WSDL- WebServicesDescriptionLanguage Status Ziele ElementeinWSDL UDDI - Universal Description, Discovery and Integration Status Ziele Merkmale UDDI-API fürjava ÖffentlicheUDDI-Registries... 13

6 VIII Inhaltsverzeichnis 3 Sicherheitsprotokolle und Standards WebServiceSecurity Status Ziele MerkmalevonWS-Security Implementierungen XML-Signature Status Ziele Merkmale Implementierungen XML-Encryption Status Ziele Merkmale Implementierungen XKMS-XMLKeyManagmentSpecification Status Ziele Implementierungen SAML - Security and Assertion Markup Language Status Ziele Implementierungen Die Axis SOAP-Implementierung DasAxis-Projekt ArchitekturvonAxis AxisalsServer AxisalsClient InstallationundKonfigurationvonAxis Installation EntwickelneinesWebServicesmitAxis ErstelleneinesJava-Interfaces Erzeugen der WSDL-Beschreibung Erzeugung der Java-Klassen aus dem WSDL-Dokument EinfügenderProgrammlogik InstallationvonWebServicesunterAxis ErstelleneinesClients SicherheitslückenvonWebServices SicherheitslückendurchXML GroßeXML-Dokumente EntityExpansionAttacks DateireferenzierendeEntities... 36

7 Inhaltsverzeichnis IX Gegenmaßnahmen SicherheitslückendurchdenEinsatzvonSOAP Sicherheit der übertragenendaten BufferOverflows Command-Injection SOAP-Attachments Gegenmaßnahmen AllgemeineSicherheitsmaßnahmen Die WS-Security Implementierung MotivationzurImplementierung Anforderungen SignierungvonNachrichten VerschlüsselungvonNachrichten AnforderungenzumpraktischenEinsatz Entwurf Realisierung Packagede.trier.wsse.type Packagede.trier.wsse.dsig Packagede.trier.wsse.enc Packagede.trier.wsse.security TestenderBibliothek Betrachtungen zum praktischen Einsatz der Implementierung IntegrationinvorhandeneWebServices Performance und Netzlast durch den Einsatz von WS-Security Performance Netzlast Fazit und Ausblick Fazit Weiterentwicklung der Bibliothek in der Zukunft Klassendokumentation Packagede.trier.wsse.type BinarySecurityToken CipherData DataReference EmbeddedReference EncryptedData EncryptedKey EncryptionMethod KeyIdentifier Reference... 60

8 X Inhaltsverzeichnis ReferenceList SecurityHeader SecurityTokenReference SignatureElement TimeStamp UsernameToken X509IssuerSerial Packagede.trier.wsse.enc CertificateResolver DecryptElement EncryptElement XEncrypt XMLDecryptor XMLEncryptor DecryptionException EncryptionException Packagede.trier.wsse.dsig SignBodyElement VerifySignedBody XSignature SignatureException Packagede.trier.wsse.security WSSecurity Packagede.trier.wsse.util EncryptionUtil SignatureUtil Packagede.trier.wsse.samples SignatureHandler VerifyingHandler UML-Diagramme der Packages Beispiele SOAP-AufrufRequest/Respone SOAP-AufrufinnerhalbeinesHTTP-Request SOAP-Antwort innerhalb einer HTTP-Response AutomatischerzeugtesWSDL-Dokument SOAP-Aufruf unter Verwendung von WS-Security SOAP-Aufruf Digital Signierter SOAP-Aufruf und Verarbeitung durcheinenproxy Digital signierter und verschlüsselter SOAP-Aufruf undverarbeitungdurcheinenproxy Abkürzungen... 87

9 Inhaltsverzeichnis XI 13 Stichwortverzeichnis Literaturverzeichnis... 95

10

11 1 Web Services - eine kurze Einführung Dieser Abschnitt gibt eine Einführung in den Aufbau und die Grundlagen von Web Services. Dabei werden die Unterschiede und Vorteile gegenüber klassischen Middleware-Architekturen herausgestellt. Anschließend folgt ein kurzer Vergleich der beiden Ansätze Sun ONE und Microsoft.NET. 1.1 Was sind Web Services? Web Services sind allgemein gesprochen Client/Server-Applikationen, die ihre Dienste über ein Netzwerk anbieten, typischerweise das Internet, aber auch ein Intranet. Meint man jedoch Web Services, von denen seit einiger Zeit die Rede ist, so kann man einschränken: Web Services sind Server-Applikationen, die mit dem Client über das auf XML basierende SOAP-Protokoll 1 kommunizieren und dazu HTTP oder SMTP als Trägerprotokoll benutzen. Neu ist daran lediglich die Kommunikation über SOAP und HTTP bzw. SMTP. Die Funktionalität wurde früher schon durch klassische Middleware-Technologien wie CORBA und das dabei benutzte Protkoll IIOP erreicht. Vereinfacht gesprochen kommunizieren Web Services durch den Austausch von XML- Dokumenten über HTTP. 1.2 Architektur von Web Services Die Architektur von Web Services lässt sich mit den vorher erwähnten klassischen Middleware-Architekturen vergleichen. Insgesamt kann man die folgenden drei Rollen vergeben: Service Requester bzw. Client Der Client nutzt die Dienste, die ein Server anbietet. Im Falle von Web 1 Simple Object Access Protocoll

12 2 1 Web Services - eine kurze Einführung Services führt der Client entfernte Methodenaufrufe auf dem Server durch, ähnlich dem lange bekannten Konzept der RPC 2. Dabei wird SOAP als Kommunikationsprotokoll benutzt. Den aufzurufenden Web Service kann der Client aus der UDDI-Registry 3 bestimmen (Find). Die UDDI-Registry ist eine Art öffentliches Verzeichnis, bei dem Anbieter ihre Web Services registrieren können. Eine ausführlichere Erläuterung von UDDI erfolgt in Kapitel 2.4. Service Provider bzw. Server Der Server stellt die Dienste bereit und veröffentlicht eine standardisierte Beschreibung (Publish), wie diese aufzurufen sind. Das kann ein WSDL- Dokument 4 zum Download sein oder ein Eintrag in einer UDDI-Registry. WSDL-Dokumente beschreiben Web Services mit einer XML-Grammatik, mehr dazu folgt in Kapitel 2.3. Service Registry bzw. Registry Hier kann der Betreiber der Web Services veröffentlichen (Publish), welche Funktionalität die angebotenen Services bieten. Diese Einträge sind ebenfalls standardisiert und erfolgen mittels UDDI. Abb Ablauf der Nutzung eines Web Service 1.3 Vergleich zwischen Sun ONE und Microsoft.NET Dieser Abschnitt zieht einen kurzen Vergleich zwischen den beiden bedeutendsten Architekturen zur Realisierung von Web Services, Sun ONE und Mi- 2 Remote Procedure Calls 3 Universal Description, Discovery and Integration 4 Web Service Description Language

13 1.3 Vergleich zwischen Sun ONE und Microsoft.NET 3 crosoft.net. Am Ende soll eine kurzes Fazit die Vor- und Nachteile aufzeigen, jedoch ohne eine Bewertung der beiden Ansätze durchzuführen Sun ONE Der Ansatz von Sun basiert auf dem Einsatz von Enterprise Java Beans, die die Geschäftslogik implementieren. EJBs kommunizieren mit der oder den Datenbanken, die Datenpräsentation auf der Clientseite geschieht mit JSPs oder Servlets. Sie erzeugen das vom Browser darstellbare HTML. Im Falle von Web Services kommuniziert der Client über SOAP mit dem Server, die SOAP-Anfragen werden dann auf Serverseite von einem Router-Servlet entgegengenommen. Das Router-Servlet greift seinerseits wieder auf die EJBs zu. Dabei ist die Programmiersprache in der der Client entwickelt wurde beliebig. Eine weitere Möglichkeit besteht im Einsatz von CORBA/RMI mit IIOP als Kommunikationsprotokoll zwischen Client und Server, damit kann der Client direkt auf die EJB-Umgebung zugreifen, siehe dazu Abb.1.2. Diese zweischichtige Architektur ermöglicht die klare Trennung zwischen präsentierenden (JSP, Servlets) und geschäftslogischen Funktionen (EJBs). Die EJB-Umgebung ist zudem absolut plattformunabhängig. Zur Entwicklung Java-basierter Lösungen steht eine Vielzahl eigenständiger Abb Die Sun ONE-Architektur

14 4 1 Web Services - eine kurze Einführung Produkte zur Verfügung. Von Sun gibt es die Forte Entwicklungsumgebung, andere IDEs sind NetBeans, VisualJ oder Eclipse. Als Application-Server sind der Sun ONE Application Server, JBoss, Jonas und andere auf dem Markt. Diese Produkte sind eigenständige Lösungen, die nicht aufeinander abgestimmt sind und nur mit Anpassungen zusammenarbeiten. Auch wenn Sun mit der ONE Initiative eine Komplettlösung ähnlich.net bieten will, merkt man doch recht schnell, daß hier, vorerst, nur vorhandene Produkte zu einem Paket zusammengefasst wurden. Während der Entwicklung muss ein Web Service kompiliert, von Hand installiert und anschließend ein Client zum Testen codiert werden. Zwar erleichtern einige Tools (wie beispielsweise in der Axis-Bibliothek) die Entwicklung, diese sind aber nicht in die Entwicklungsumgebung integriert und müssen von Hand aufgerufen oder eingebunden werden Microsoft.NET Die.NET-Architektur ähnelt stark derjenigen von Sun ONE. Der einzige Unterschied besteht darin, dass die Möglichkeit mit CORBA/RMI über IIOP zu kommunizieren, entfällt. Stattdessen kommt (D)COM als Protokoll zum Einsatz, mit dem der Client direkt auf die.net-komponenten im Kern des Gesamtsystems zugreifen kann, siehe Abb.1.3. Diese.NET-Komponenten werden mit einer beliebigen, von.net unterstützten Programmiersprache entwickelt, ebenso der Client. Auf den ersten Blick kann Java dann durch.net mit VisualBasic kommunizieren, was vorher so nicht möglich war. Dies stimmt sogar, allerdings ist dieser Ansatz nur sprachunabhängig und nicht plattformneutral. Der Microsoft-Ansatz erfordert immer eine Microsoft-Plattform, vielleicht wird diese Notwendigkeit in Zukunft durch das Mono-Projekt und.gnu unter Linux entfallen. Als Entwicklungsumgebung steht zur Zeit für.net nur das VisualStudio.NET von Microsoft zur Verfügung, andere Produkte sind noch keine vollwertigen IDEs, sondern eher Quellcodeeditoren. Dazu, quasi als Paket, bietet Microsoft den Internet Information Server als Application Server an, der zusammen mit dem Internet Explorer als Test- und Ablaufumgebung dient. Die Unterstützung des Internet Information Servers aus VisualStudio heraus ist weit fortgeschritten, so ist es möglich, mit nur einem Knopfdruck einen entwickelten Web Service zu installieren, starten und zu testen Fazit Beide Ansätze bieten Vor- und Nachteile. Der wichtigste Vorteil des Javabasierten Ansatzes ist natürlich die Plattformneutralität, da Java auf allen gängigen Betriebssystemen verfügbar ist. Demgegenüber steht die bislang schlechte Unterstützung durch die erhältlichen Entwicklungsumgebungen, hier besteht noch einiger Nachholbedarf durch die Hersteller. Momentan muss an dieser Stelle noch zuviel Handarbeit geleistet werden.

15 1.4 Vor- und Nachteile von Web Services 5 Abb Die Microsoft.NET-Architektur Microsoft bietet mit der.net-plattform, der Visual-Studio-Entwicklungsumgebung und dem Internet Information Server ein sehr mächtiges System, mit dem Web Services schnell entwickelt, getestet und installiert werden können. Ein Nachteil ist die Bindung an eine komplette Umgebung dieses Anbieters, da sonst die Stärken des aufeinander abgestimmten Systems nicht mehr zum Tragen kommen. 1.4 Vor- und Nachteile von Web Services Der Vorteil von Web Services gegenüber klassischen Middleware-Techniken liegt in der Plattformneutralität. Ein Client muss nicht wissen, in welcher Sprache ein Service programmiert ist oder unter welchem Betriebssystem er läuft. Er benötigt lediglich die Information aus der Registry, also ein WSDL- Dokument oder einen Eintrag aus einer UDDI-Registry, um zu wissen, wie der Service zu nutzen ist. Ein weiterer positiver Aspekt (und gleichzeitiger Schwachpunkt) ist die Verwendung von HTTP als Trägerprotokoll. Andere TCP/IP-basierte Middleware- Technologien kommunizieren über einen priviligierten Port; dieser muss an einer Firewall explizit freigeschaltet werden. Bei der Nutzung von HTTP ist dies nicht notwendig, da der verwendete Port 80 für HTTP beinahe immer

16 6 1 Web Services - eine kurze Einführung geöffnet ist. Allerdings wird dadurch auch die Sicherheitsfunktion der Firewall untergraben, weil der Datenverkehr jetzt ungefiltert passieren kann. Ein weiterer Minuspunkt ist die ungesicherte Kommunikation zwischen Client und Server, alle Daten werden im Klartext übertragen und können so abgehört oder manipuliert werden. Hier müssen zusätzliche Sicherheitsmaßnahmen Berücksichtigung finden.

17 2 Standards im Bereich Web Services In diesem Kapitel werden Standards beschrieben, die im Umfeld von Web Services von Bedeutung sind. Diese Standards, XML, SOAP, WSDL und UDDI, sind die Basis für die Implementierung und den Betrieb von Web Services. 2.1 XML - Extensible Markup Language Status Extensible Markup Language (XML) 1.0 (Second Edition) W3C Recommendation 6. Oktober 2000 Aktuelle Version: Merkmale Da XML im Vergleich zu den anderen vorgestellten Standards schon auf weite Anwendungsfelder zurückblickt und nicht speziell für den Einsatz innerhalb von Web Services entwickelt wurde, wird hier nicht näher auf die Eigenheiten von XML eingegangen. Das wesentliche Merkmal von XML liegt in der Bereitstellung eines einheitlichen Datenformates zum Austausch strukturierter Informationen. Diese Eigenschaft wird sehr gut beim Einsatz von XML innerhalb von Web Services sichtbar, hier werden Daten zwischen verschiedensten Plattformen ausgetauscht und einheitlich verarbeitet. Für weitere Informationen zu XML sei auf die Webseite des W3C verwiesen, Empfehlenswerte Bücher zum Thema XML sind [2] und [3].

18 8 2 Standards im Bereich Web Services 2.2 SOAP - Simple Object Access Protocol Status Simple Object Access Protocol (SOAP) 1.2 W3C Note 8. Mai 2000 Aktuelle Version: Ziele Die SOAP-Spezifikation beschreibt ein einfaches Protokoll zum Austausch strukturierter Informationen in einer dezentralen, verteilten Umgebung mit XML. Dabei macht sie keine Aussagen über das Programmiermodell oder Implementierungsdetails der Anwendung, es wird lediglich ein Mechanismus entworfen, um Daten innerhalb verteilter Anwendungen auszutauschen. So kann SOAP mit einer Vielzahl anderer Protokolle kombiniert werden (Binding), im aktuellen Standard ist vorerst nur die Bindung an HTTP spezifiziert. Oberstes Design-Ziel war die Einfachheit und Erweiterbarkeit des Protokolls; so wurde bei der SOAP-Spezifikation auf einige Merkmale traditioneller Messaging- oder Distributed-Object-Systeme wie CORBA oder RMI bewusst verzichtet. Aufgrund der Zustandslosigkeit von Web Services fehlen unter anderem folgende vier Kernfunktionalitäten, die von Middleware- Frameworks bereitgestellt werden: Object-by-Reference Verteilte Garbage Collection Activation Messaging, bzw. Message-Queues Weiterhin werden in der Spezifikation keine Mechanismen zur Verschlüsselung, Authentifizierung und Datenintegrität beschrieben, diese Aufgaben müssen durch zusätzliche Maßnahmen abgedeckt werden Merkmale Die SOAP-Spezifikation besteht aus 3 Teilen: SOAP Envelope Der SOAP-Envelope (Umschlag) definiert eine Struktur, mit der definiert werden kann, was in der SOAP-Nachricht enthalten ist, wer der oder die Empfänger sind und welche Teile des Inhaltes vorgeschrieben oder optional sind. SOAP Encoding Rules Die SOAP Encoding Rules beschreiben einen Mechanismus zur Serialisierung von Anwendungsdaten, die dann innerhalb des erzeugten XML- Dokuments ausgetauscht werden können.

19 2.2 SOAP - Simple Object Access Protocol 9 SOAP RPC - SOAP Remote Procedure Calls SOAP-RPC beschreibt eine Konvention zur Repräsentierung von RPC- Aufrufen und RPC-Rückgaben in XML. Damit ist es möglich, mit Hilfe von SOAP entfernte Prozeduren aufzurufen, also verteilte Anwendungen zu implementieren. Der Prozeduraufruf über SOAP hat den Vorteil, keine Änderung an bestehenden Netzwerkkonfigurationen zu benötigen, da er über das übliche HTTP-Protokoll an Port 80 durchgeführt wird. Eine gültige SOAP-Nachricht besteht aus einem SOAP-Envelope, einem optionalen SOAP-Header und einem SOAP-Body. Zusätzlich können an die Nachricht noch Attachments in Form von Dateien angefügt werden. SOAP-Envelope Der Envelope repräsentiert das Wurzelelement einer SOAP-Nachricht. Er enthält die Namespace-Deklarationen für SOAP xmlns:soap-env= und eventuell zusätzliche Attribute, welche durch eine Namespace-Deklaration qualifiziert werden müssen. SOAP-Header Der Header stellt das erste Folgeelement des SOAP Envelope dar. Hiermit wird der Empfänger einer Nachricht, der sogenannte SOAP-actor, festgelegt. Es können auch sogenannte Intermediaries (Zwischenempfänger) angegeben werden. Diese empfangen die Nachricht und leiten sie an den Empfänger oder an den nächsten Intermediary weiter, wobei Teile der Nachricht geändert werden können. Dies wird wichtig im Zusammenhang mit der Verschlüsselung oder Signatur der Nachricht, da dann berücksichtigt werden muss, welche Teile der verschlüsselten Nachricht ein Intermediary lesen oder ändern können soll. Eventuell ist auch ein erneuter Signaturvorgang erforderlich. Weiter wird im Header durch das Attribut mustunderstand festgelegt, ob der Empfänger das Header-Element verabeiten muss oder ob es genügt, nur die Body- Elemente zu verarbeiten. Können die Header-Einträge nicht verarbeitet werden, muss die SOAP-Engine einen SOAP-Fehler (SOAP-Fault) erzeugen, der dann als Rückgabe innerhalb der Response im SOAP-Body steht. Anhand dieses SOAP-Faults kann der Absender dann ermitteln, weshalb sein SOAP- Aufruf nicht erfolgreich bearbeitet werden konnte. SOAP-Body Das Body-Element ist ein child-element des SOAP Envelope. Ist ein SOAP- Header-Element vorhanden, muss der SOAP-Body auf dieses folgen, ist kein Header-Element vorhanden, folgt es unmittelbar auf das SOAP-Envelope- Element. Der Body enthält die eigentlichen Nutzdaten, die an den Empfänger

20 10 2 Standards im Bereich Web Services übertragen werden, dies können RPC-Aufrufe oder Fehlermeldungen sein. Alle Einträge im Body sind durch Namespace-Deklarationen auszuzeichnen. Für SOAP-Fehlermeldungen gibt es das SOAP Fault-Element mit den 4 Subelementen faultcode, faultstring, faultactor und detail. Andere Subelemente sind zugelassen, müssen dann aber qualifiziert werden. Abb Aufbau einer SOAP-Nachricht Implementierungen Apache Axis Apache SOAP Microsoft.NET Framework Sun Web Services Development Kit ksoap Einen SOAP-Request und SOAP-Response über HTTP als Trägerprotokoll zeigt Beispiel 11.1.

21 2.3 WSDL - Web Services Description Language WSDL - Web Services Description Language Status Web Services Description Language (WSDL) 1.1 W3C Note 15. März 2001 Aktuelle Version: Ziele WSDL definiert eine XML-Grammatik zur Beschreibung von Web Services. Dazu beschreibt ein WSDL-Dokument einen Service als Endpunkt, an den Nachrichten versendet werden. Ein WSDL-Dokument kann über eine URL oder UDDI abgerufen werden, um diese Beschreibung dem Nutzer eines Services zur Verfügung zu stellen. Anhand dieses Dokumentes kann der Service dann mit den entsprechenden Parametern aufgerufen werden. In der aktuellen Version werden als Protokolle zum Nachrichtenaustausch SOAP, HTTP GET/POST und MIME unterstützt Elemente in WSDL service-element Die Adresse des Web Service, bei Nutzung von HTTP als Trägerprotokoll beispielsweise Die Adresse eines Web Service bildet zusammen mit den nachfolgenden Elementen des WSDL- Dokumentes den sogenannten service. types-element Dieses Element dient zur Definition der Datentypen, die in den Nachrichten ausgetauscht werden, sowie der zugehörigen Rückgabewerte. Um die Plattformunabhängigkeit und Interoperabilität zu gewährleisten, benutzt WSDL dazu XSD-Schemas. Es können aber auch neue, eigene Typsysteme verwendet werden. message-element Beschreibt die Ein- und Ausgabeparameter. operation-element Legt die vom Web Service unterstützten Methodensignaturen fest. porttype-element Definiert die Zuordnung der einzelnen öffentlich angebotenen Methoden zu den Methoden der Implementierungsklasse, die den Web Service realisiert. binding Beschreibt das konkrete Trägerprotokoll und Datenformat über das kommuniziert wird. Dies wird als Binding bezeichnet. port -Element Definiert den Endpunkt der Kommunikation als Kombination aus Binding und Netzwerkadresse. Ein automatisch aus einem Java-Interface generiertes WSDL-Dokument zeigt Beispiel 11.2.

22 12 2 Standards im Bereich Web Services 2.4 UDDI - Universal Description, Discovery and Integration Status Universal Description, Discovery and Integration Aktuelle Version 3.0: Ziele UDDI definiert ein webbasiertes, verteiltes System zur Registrierung von Web Services. Ziel ist es, Firmen die Möglichkeit zu geben, die von ihnen angebotenen Web Services in einer Art öffentlichem Verzeichnis, den UDDI-Registries, einzutragen. Diese Einträge können dann nach verschiedenen Kriterien durchsucht werden, um den passenden Anbieter eines Web Service zu finden. Die Beschreibung eines Web Service erfolgt dabei durch eine XML-Datei. In der neuesten Version 3 der Spezifikation wird zusätzlich die Sicherheit der eingetragenen Informationen berücksichtigt. Es wird damit in Zukunft möglich sein, UDDI-Einträge digital zu signieren, um die Integrität der Informationen sicherzustellen. So kann beispielsweise verhindert werden, dass die Adresse eines Web Services unerlaubt verändert wird und damit SOAP-Anfragen an die Adresse eines falschen Servers gesendet werden Merkmale Die UDDI-Spezifikation unterteilt sich in vier Hauptbestandteile: Datenstruktur Mit ihr wird beschrieben, welche Datentypen innerhalb von UDDI gespeichert werden sollen. Ähnlich wie WSDL wird auch UDDI mit Hilfe von XML-Schemas beschrieben. API-Spezifikation Diese Spezifikation beschreibt, wie man als Programmierer auf eine UDDI- Registry zugreifen kann. Dabei gibt es zwei Gruppen von Funktionen. Die sogenannten publishing functions dienen dem Eintragen und Updaten eines Dienstes in der Registry. Zum Auslesen dieser Informationen benötigt man die inquiry functions, mit denen Lesezugriffe auf die UDDI-Registries durchgeführt werden können. Die API ist programmiersprachenunabhängig und muss in die jeweils benötigte Programmiersprache übersetzt werden. Replikationsspezifikation In dieser Spezifikation wird festgelegt, wie zwischen verschiedenen Anbietern die Daten unterschiedlicher UDDI-Registries dupliziert werden können.

23 2.4 UDDI - Universal Description, Discovery and Integration 13 Spezifikation für Registry-Anbieter Diese Spezifikation ist für Unternehmen gedacht, die selber eine UDDI- Registry aufbauen möchten. Sie umfasst Details über einzuhaltende Sicherheitsmaßnahmen, damit ein standardisierter Zugriff auf alle Registries erfolgen kann. Die Beschreibung eines Web Services innerhalb einer Registry wird in vier Teile untergliedert: Business Information Hierunter versteht man allgemeine Informationen über den Anbieter des Web Service, also Firmenname, Branche oder spezielle Produktinformationen, die im Zusammenhang zum Web Service stehen. Service Information Mit diesem Element können mehrere Web Services zu einem Prozess zusammengefasst werden, damit dieser durch den Aufruf aller Services abgearbeitet werden kann. Binding Information Hiermit werden technische Aspekte des Web Service beschrieben, beispielsweise unter welcher Adresse er zu finden ist, wie das Routing zum Service verläuft oder welche Maßnahmen zum Load Balancing zu beachten sind. Specification Information Hier werden die zum Aufruf des Service wichtigen Informationen eingetragen. Dazu gehören die Parameter, die übergeben werden müssen, das Format der Antwort oder zusätzliche Informationen zur Sicherheit UDDI-API für Java UDDI4J von IBM Java-API zum Zugriff auf UDDI-Registries, kostenlos unter Öffentliche UDDI-Registries IBM Microsoft SAP HP

24

25 3 Sicherheitsprotokolle und Standards Dieser Abschnitt beschreibt die wichtigsten Protokolle und Standards im Zusammenhang mit der Absicherung von Web Services. Es werden die jeweils wichtigsten Bestandteile kurz beschrieben, um die Möglichkeiten des entsprechenden Protokolls darzustellen. 3.1 Web Service Security Status Specification: Web Services Security (WS-Security) Working Draft 17, 27. August 2003 Aktuelle Version: Vorgeschlagen von IBM, Microsoft, Verisign Addendum: Web Services Security Addendum, 18. August Ziele Ziel des WS-Security-Standards ist der sichere Austausch von SOAP-Nachrichten. Dazu erweitert die Spezifikation vorhandene Sicherheitsprotokolle wie XML-Signature und XML-Encryption, um den Austausch von Sicherheitsinformationen, die Nachrichtenintegrität und die Vertraulichkeit von Nachrichten sicherzustellen. In der Spezifikation wird ausdrücklichdaraufhingewiesen, daß allein der Einsatz von WS-Security noch keine sicheren Web Services gewährleistet: (...) WS-Security is a building block that can be used in conjunction with other Web Service extensions and higher-level applicationspecific protocols to accommodate a wide variety of security models and encryption technologies. [6]

26 16 3 Sicherheitsprotokolle und Standards Um das Ziel sicherer Web Services zu erreichen, entwirft die Spezifikation kein eigenes Protokoll, sondern ein flexibel erweiterbares Framework, daß auf vorhandenen Sicherheitsstandards aufsetzt und die Integration zukünftiger Protokolle ermöglicht. WS-Security gewährleistet dabei eine Ende-zu-Ende- Sicherheit der ausgetauschten XML-Dokumente. Es erweitert die in der SOAP- Spezifikation festgelegten Header-Elemente um neue Elemente, die es ermöglichen, Sicherheitsinformationen in das XML-Dokument zu integrieren. Spätere Spezifikationen wie WS-Policy (gerade verabschiedet), WS-Trust oder WS- Privacy werden auf WS-Security aufbauen, um dieses Framework zu erweitern. Abb Die WS-Security Roadmap Merkmale von WS-Security Security-Element Die Spezifikation führt ein Security-Element im Header der SOAP-Nachricht ein, dass zum Anfügen von Sicherheitsinformationen für einen bestimmten Empfänger oder Intermediary in die SOAP-Nachricht dient. Für jeden Intermediary/Empfänger kann dabei ein eigenes Security-Element eingefügt werden. So können unterschiedliche Sicherheitsanforderungen an verschiedene Empfänger adressiert werden. Ein Intermadiary kann neue Security-Elemente anfügen oder bestehende Einträge ändern. Der Security-Header stellt also eine Beschreibung dar, welche Schritte der Absender durchgeführt hat, um die Nachricht zu signieren und/oder zu verschlüsseln. UsernameToken-Element Innerhalb des Security-Elementes wird das UsernameToken-Element verwendet. Es dient zur Übermittlung eines Benutzernamens mit optionalem Passwort.

27 3.2 XML-Signature 17 BinarySecurityToken-Element Zur Übermittlung binärer (z.b. X.509 Zertifikate, Kerberos Tickets) Security Token dient das BinarySecurityToken-Element. Es definiert die Art der Information, sowie die Binärkodierung (z.b. Base64Binary), die durchgeführt wurde, um das Token in das XML-Dokument einzubinden. SecurityTokenReference-Element Für Tokens, die nicht in der SOAP-Nachricht enthalten sind, sondern extern über eine URI referenziert werden, ist das SecurityTokenReference- Element vorgesehen. Es kann beispielsweise dazu verwendet werden, über eine URI einen Schlüssel zu referenzieren, der zur Verifizierung einer Signatur benötigt wird. TimeStamp-Element Das TimeStamp-Element ermöglicht die Angabe des Erstellungs- und/oder Verfallszeitpunktes für ein XML-Dokument. Optional können auch Delays angegeben werden, die die Dauer der Übertragung oder Verarbeitung des Dokumentes beschreiben. Andere Elemente werden aus den Standards XML-Encryption/XML-Signature übernommen, ihre Beschreibung erfolgt in den beiden nächsten Abschnitten. Ein Beispiel zur Benutzung von WS-Security innerhalb eines SOAP-Aufrufes findet sich unter Beispiel Implementierungen Microsoft Web Service Development Kit für.net 3.2 XML-Signature Status XML-Signature Syntax and Processing W3C Recommendation 12 Februar 2002 Aktuelle Version: Ziele Die XML-Signature-Spezifikation beschreibt eine Syntax und dazugehörige Verarbeitungsregeln zur Erzeugung und Verarbeitung von digitalen Signaturen innerhalb von XML-Dokumenten. Diese Signaturen können auf jede Art digitaler Daten angewendet werden, vor allem natürlich XML-Dokumente. Es können sowohl Daten innerhalb eines XML-Dokumentes signiert werden (Enveloped bzw. enveloping-signature), als auch externe Daten (detached- Signature). XML-Signature legt dabei die Bindung eines Schlüssels an die