Web Service Security für die IT-Grundschutz-Kataloge

Transkript

1 Web Service Security für die IT-Grundschutz-Kataloge Stefan Schleifer Bachelorarbeit Fachhochschul-Bachelorstudiengang Computer- und Mediensicherheit in Hagenberg Mai 2009

2 Inhaltsverzeichnis Kurzfassung Abstract iii iv 1 Einleitung Motivation & Herausforderung Zielsetzung Gliederung Grundlagen von Web Services Architektur SOAP Aufbau einer SOAP-Nachricht RPC mit SOAP WSDL Verzeichnisdienste Organisation & Geschäftsprozesse Sicherheit von Web Services WS-*-Familie WS-Policy WS-Trust XML-Sicherheit XML-Signature XML-Encryption SAML XACML IT-Grundschutz IT-Grundschutz-Vorgehensweise Webdienste-Baustein Gefährdungen Maßnahmen i

3 INHALTSVERZEICHNIS ii 5 Fazit und Ausblick 65

4 Kurzfassung Web Services nehmen in der IT-Strategie vieler Unternehmen eine immer gr oßere Rolle ein. Web Services sind autonome Dienste und k onnen flexibel, d.h. lose und unabhängig von anderen als den kombinierten Diensten, miteinander kombiniert werden, um einen Mehrwert für ein Unternehmen zu kreieren. Aufgrund der sich dadurch ergebenden starken Vernetzung nehmen jedoch auch die Sicherheitsanforderungen an die Web Services selbst sowie deren Umgebung ständig zu. Um Web Services auch bei unternehmenskritischen Anwendungen zu verwenden, muss deren Sicherheit gewährleistet sein. Dazu muss neben der Vertraulichkeit, Integrität und Nichtleugenbarkeit der übermittelten Daten ebenso die korrekte Zugriffskontrolle sichergestellt werden. Die WS-* Standards sowie XML-Signature und XML-Encryption als auch die Security Assertion Markup Language (SAML) und extensible Authentication Markup Language (XACML) adressieren die eben genannten Anforderungen und bieten plattform- und programmiersprachenneutrale Lösungen an. Die Diskussion dieser L osungen sowie das Identifizieren von Gef ahrdungen als auch die Entwicklung entsprechender Gegenmaßnahmen bilden den Kern der vorliegenden Arbeit. Da seitens der Informationssicherheitsverantwortlichen und IT-Leiter laut [34] ein entsprechender Bedarf besteht, wird, basierend auf die in dieser Arbeit gewonnen Erkenntnisse ein IT-Grundschutz-Baustein erstellt. Das Bundesamt f ur Sicherheit in der Informationstechnik (BSI) ver offentlicht in regelm aßigen Abst anden die IT-Grundschutz-Kataloge, welche in Form von Bausteinen die Sicherheit verschiedener Systeme und Anwendungen behandeln. Der erstellte Baustein bietet einen Uberblick uber das Thema Web Services und stellt dann die identifizierten Gefährdungen sowie entsprechende Gegenmaßnahmen dar. iii

5 Abstract Web Services increasingly play a major role in many company s IT-strategy. Web Services are autonomous systems which may be combined individually in order to generate a surplus for the business. Along with this combination and the resulting crosslinking, the security requirements of Web Services as well as their environment increase too. For the purpose of using Web Services for business critical applications, the security of Web Services must be ensured. Besides confidentiality, integrity and non-repudiation, accurate access control is another key factor to be assured. The WS-*-Standards, XML-Signature and XML-Encryption as well as Security Assertion Markup Language (SAML) and extensible Authentication Markup Language (XACML) provide platform- and languageindependent solutions. Both, discussing these approaches and identifying potential threats and developing accordant countermeasures form present thesis quintessence. As chief security officer and chief information officer appreciate the creation, an IT-Grundschutz-Baustein based on the findings in this thesis is created. The Federal Office for Information Security (BSI) releases the IT Grundschutz-Kataloge on a regular base, which deal with both, system- and application security. The newly created Baustein about Web Services provides an overview of Web Services and furthermore depicts identified threats as well as accordant countermeasures. iv

6 Kapitel 1 Einleitung 1.1 Motivation & Herausforderung Service-orientierte Architekturen (SOA) werden in zunehmendem Maße in IT-Landschaften von Unternehmen jeder Große und Branche eingesetzt. Durch Service-orientierte Architekturen hält ein neues Paradigma Einzug in Unternehmen, durch welches der Versuch unternommen wird, der zunehmenden Komplexit at und Heterogenit at von IT-Landschaften mit einer weiteren Abstraktionsstufe zu begegnen. In einer SOA treten, im Gegensatz zur komponentenbasierten Softwareentwicklung, die Implementierung und damit die technischen Aspekte der Systeme in den Hintergrund. Stattdessen werden nur noch abstrakte Dienste (Services) nach außen zur Verfügung gestellt. Um eine SOA umzusetzen werden häufig Web Services verwendet. Web Services bieten ihre Funktionalit at und Informationen uber in standardisier ter Form beschriebenen, XML-basierten Schnittstellen anderen Systemen an. Insbesondere die lose Bindung der einzelnen Komponenten untereinander sowie das Vorhandensein von Verzeichnisdiensten (vgl. Seite 14) zum Auffinden von Web Services kommen der Geschäftsprozessmodellierung entgegen. Des Weiteren können Web Services auch in bereits vorhandene, heterogene Infrastrukturen integriert werden, da zur Kommunikation etablierte Technologien wie HTTP oder XML zum Einsatz kommen. Aus den Anforderungen an die mit Web Services implementierten Geschäfsprozesse ergeben sich jedoch auch neue Anforderungen an die Verfügbarkeit, Integrität und Vertraulichkeit dieser Dienste und Daten. Als Folge dessen spielt das Thema Sicherheit bei Web Services und SOA eine entscheidende Rolle und kann darüber entscheiden, ob sich dieser Technologieansatz durchsetzt. Die IT-Grundschutz-Standards 1 des Bundesamts für Sicherheit in der In 1 URL: standard/index.htm. Abgerufen am 1

7 KAPITEL 1. EINLEITUNG 2 formationstechnik (BSI) stellen einen weit verbreiteten Ansatz zur Harmonisierung und Etablierung einer einheitlichen Informationssicherheitspolitik innerhalb von Organisationen und Unternehmen dar. Mit den IT-Grundschutz- Standards existiert eine pauschalisierte Vorgehensweise, um den Umfang und Aufwand von Risikoanalysen zu reduzieren. Da in vielen Informationsverbunden ahnliche Risiken herrschen, ver offentlicht das BSI die IT Grundschutz-Kataloge 2. Dazu werden so genannte Bausteine entwickelt, die die f ur das Thema des Bausteins h aufigsten Gef ahrdungen und entsprechende Sicherheitsmaßnahmen enthalten. Eine vom BSI durchgeführte Umfrage [34] unter mehr als 300 registrierten Anwendern unterstreicht die Wichtigkeit von Web Service Security. 65,2 Prozent der Anwender wünscht sich einen Baustein zum Thema Webanwendungen und befürwortet die Erstellung eines solchen. 1.2 Zielsetzung Das Ziel dieser Arbeit ist es, das Thema Web Services, unter Berücksichtigung von geschäftsprozessrelevanten Aspekten, aus technischer Sicht zu erläutern und die sicherheitsrelevanten Aspekte herauszuarbeiten und weiterführende Informationen zur Absicherung dieser Dienste zu geben. Neben der ausführlichen Behandlung der relevanten technologischen Grundlagen sollen vor allem die h aufigsten Gef ahrdungen f ur Web Services identifiziert und darauf aufbauend entsprechende Gegenmaßnahmen entwickelt werden. Die in der Arbeit gefundenen und diskutierten Angriffspunkte (siehe Seite 53ff) sowie die verschiedenen Möglichkeiten, diesen Angriffen entgegen zu wirken (Seite 57ff) sollen in einen Baustein für die IT-Grundschutz-Kataloge einfließen. Das Ergebnis des vorliegenden Dokuments sind zumindest umfangreiche Vorarbeiten für einen solchen Baustein. 1.3 Gliederung In Kapitel 2 Grundlagen von Web Services werden primär die technologischen Grundlagen von Web Services erlautert, da das hier gewonnene Verst andnis essentiell f ur die weiteren Kapitel, insbesondere zur Absiche rung von Web Services, ist. Zu diesen technischen Grundlagen zählen SOAP, das von Web Services zum Austausch von Nachrichten benutzte Protokoll, die Beschreibungssprache WSDL (Web Service Describtion Language) als auch die Verzeichnisdienste UDDI (Univsersal Describtion Discoverty and Integration) bzw. WS-Inspection. Neben dem Architektur-Dreieck (Entwickler, Verzeichnisdienst und Konsument) von Web Services werden in diesem Kapitel auch geschäftsprozessrelevante Aspekte behandelt URL: Abgerufen am

8 KAPITEL 1. EINLEITUNG 3 Der Fokus von Kapitel 3 liegt in weiterer Folge auf der Sicherheit vom Web Services. Aufbauend auf einer allgemeinen Einf uhrung in die WS-* Standards werden relevante Standards wie WS-Policy und WS-Trust vorgestellt. Besonders die Möglichkeit Vertraulichkeit (XML-Encryption) und Integrität (XML-Signature) der mittels SOAP ausgetauschten XML-Nachrichten sicherzustellen, nimmt einen großen Platz ein. Des Weiteren werden die Security Assertion Markup Language (SAML) sowie XACML (extensible Access Control Markup Language), eine XML-basierte Auszeichnungssprache zur Beschreibung von Sicherheitsrichtlinien, in diesem Kapitel behandelt. Kapitel 4 stellt schließlich die IT-Grundschutz-Vorgehensweise vor, bevor dann die h aufigsten Gef ahrdungen, Angriffe und Gegenmaßnahmen disku tiert werden. Im letzten Kapitel werden die gewonnen Erkenntnisse zusammengefasst sowie ein Ausblick auf die Zukunft des Themenkomplexes Web Services und dessen Sicherheitsaspekte gegeben.

9 Kapitel 2 Grundlagen von Web Services Web Services werden u.a. zur Umsetzung einer Service-orientierten Architektur verwendet. Um diese Dienste sicher gestalten zu können, ist es wichtig, sich die Architekturprinzipien und zugrunde liegenden Techniken zu verdeutlichen. Dieses Kapitel dient daher dazu, die Grundlagen von SOAP, WSDL und UDDI bzw. WS-Inspection zu vermitteln. Da Web Services eine komplexe Thematik sind und divergierende Meinungen existieren, was einen Web Service ausmacht, ist es schwierig, eine einheitliche Definition zu finden. Das W3C definiert Web Services wie folgt: Web services provide a standard means of interoperating between different software applications, running on a variety of platforms and/or frameworks. Web services are characterized by their great interoperability and extensibility, as well as their machine-processable descriptions thanks to the use of XML. They can be combined in a loosely coupled way in order to achieve complex operations. Programs providing simple services can interact with each other in order to deliver sophisticated added-value services. [4] Aus dieser Definition lassen sich die grundsätzlichen Eigenschaften von Web Services ableiten. Der erste Punkt ist die Kommunikation von Anwendungen untereinander. Mit der Einführung von Web Services tritt die Kommunikation zwischen Anwendungen respektive den Computern selbst in den Vordergrund. Zum Nachrichtenaustausch wird bei Web Services das XML-basierte SOAP verwendet. Der SOAP-Standard [8] beschreibt, wie ein übertragenes XML-Dokument aufgebaut sein muss, damit es als SOAP-Nachricht interpretiert werden kann. 4

10 KAPITEL 2. GRUNDLAGEN VON WEB SERVICES 5 Um die Interoperabilit at verschiedener Dienste sicherzustellen, m ussen die Schnittstellenbeschreibungen in maschinenlesbarer Form vorliegen. Definition 1 Unter Maschinenlesbarkeit werden Daten, zum Beispiel der Strichcode auf Lebensmittelverpackungen, verstanden, die einem Gerät bei der Identifikation und Verarbeitung von Informationen helfen, sodass diese Geräte die Informationen ohne menschliches Zutun auswerten können. Im Web Services-Umfeld sind das Metadaten, die mit einer standardisierten Struktur beschreiben, welche Informationen ein Dienst zur Verfügung stellt und wie diese Informationen von externen Diensten angefordert werden können. Dazu wird die ebenfalls XML-basierte Beschreibungssprache Web Service Describtion Language (WSDL) verwendet. Neben SOAP und WSDL stellt ein Verzeichnisdienst (UDDI oder WS- Inspection) eine weitere Komponente einer Web Services-Architektur dar. Definition 2 Ein Web Service ist ein autonomer Dienst, der seine Informationen anderen Anwendungen über standardisierte, maschinenlesbare, XML-basierte Schnittstellen zur Verfügung stellt und durch das Kombinieren mit anderen Services einen Mehrwert für ein Unternehmen generiert. Auf diese drei Komponenten sowie die allgemeine Architektur von Web Services wird nachfolgend näher eingegangen. 2.1 Architektur Eine Web Services-Architektur besteht grundsätzlich aus drei Teilnehmern. Der Anbieter stellt durch den Web Service eine gewisse Funktionalität zur Verfügung. Dazu wird eine Schnittstellenbeschreibung als XML-Dokument in einem Verzeichnisdienst veröffentlicht. Definition 3 Ein Verzeichnisdienst (engl. directory service) ist eine zentrale Datenbank mit Informationen bestimmter Art (z.b. über Personen) und dient zum Auffinden und Bereitstellung genau dieser Informationen. In diesem Verzeichnisdienst können die Konsumenten nach Web Services mit einer gewisser Funktionalität suchen und diese dann dynamisch in eigene Anwendungen einbinden. Die Kommunikation zwischen den Diensten erfolgt mittels SOAP-konformen XML-Nachrichten über HTTP oder ein anderes Transportprotokoll. Abbildung 2.1 illustriert dieses Konzept. Etwas technischer ist die Sicht auf eine von Web Services orchestrierte SOA in Abbildung 2.2 dargestellt. Die unterste Schicht stellt die Transportschicht dar. Auch wenn Web Services in erster Linie HTTP verwenden, können hier auch andere Protokolle wie zum Beispiel SMTP verwendet werden.

11 KAPITEL 2. GRUNDLAGEN VON WEB SERVICES 6 Diensteverzeichnis (UDDI) (1) veröffentlicht WSDL (3) liefert Referenz auf Dienst (2) sucht Dienst Diensteanbieter (4) Holt sich WSDL & nutzt Dienst Konsument Abbildung 2.1: Web Services-Architektur. [5, S.14] Business Process Mgmt. Federation/Routing Meta daten (UDDI, WSDL) Security Protokoll (SOAP) XML-Spezifikationen Transportschicht Abbildung 2.2: Web Services-Stack. [5, S.58]

12 KAPITEL 2. GRUNDLAGEN VON WEB SERVICES 7 Darauf aufbauend befinden sich Standards wie XML, XSD und Namespaces im Bereich der XML-Spezifikationen. Definition 4 XML Schemas express shared vocabularies and allow machines to carry out rules made by people. They provide a means for defining the structure, content and semantics of XML documents. 1 Definition 5 XML namespaces provide a simple method for qualifying element and attribute names used in Extensible Markup Language documents by associating them with namespaces identified by URI references. 2 Zur Ubertragung der XML-Nachrichten wird SOAP (früher Simple Object Access Protocol, heute kein Akronym mehr) verwendet, auf das im nächsten Kapitel näher eingegangen wird. Uber SOAP befindet sich die für Web Services wichtige Schicht der Sicherheit, da das sichere Betreiben von Web Services die Basis für die weite Adaption und Akzeptanz von Web Services in unternehmenskritischen Applikationen darstellt. Auf dieser Ebene setzt der WS-Security-Standard mit WS-Policy und WS-Trust oder auch die SAML (Security Assertion Markup Language) an. Die n achsth ohere Schicht ist f ur die Bereiche Identity Management, d.h. zur Verwaltung von Benutzern und deren Rechte innerhalb eines Systems, sowie Routing, also die Ubermittlung von Nachrichten von einem Punkt zu einem anderen, zuständig. Hier setzen die Standards WS-Routing sowie WS-Federation an. Die oberste Schicht richtet sich nicht nach den technischen Merkmalen von Systemen sondern nach Vorgaben der Unternehmensleitung und den entsprechendne Geschäftsprozessen. In der obersten Schicht wird die Koordination, Integration, Planung und Modellierung von Web Services auf Basis von Geschäftsprozessen sichergestellt. In all diesen Schichten werden Metadaten verarbeitet, die von WSDL-Dokumenten oder Verzeichnisdiensten wie UDDI oder WS-Inspection zur Verfügung gestellt werden. 2.2 SOAP Mit der Betrachtung von SOAP wird in diesem Kapitel die erste von drei Hauptkomponenten einer Web Services-Architektur behandelt. Definition 6 SOAP is a lightweight protocol intended for exchanging structured information in a decentralized, distributed environment. 3 Der SOAP-Standard [8] definiert keine Details über die auszutauschenden Daten sondern spezifiziert den Aufbau einer SOAP-konformen XML-Nachricht. 1 URL: Abgerufen am URL: Abgerufen am URL: Abgerufen am

13 KAPITEL 2. GRUNDLAGEN VON WEB SERVICES Aufbau einer SOAP-Nachricht Eine SOAP-Nachricht ist ein aus drei Teilen bestehendes XML-Dokument, illustriert in Abbildung 2.3. SOAP Envelope SOAP Header SOAP Body Abbildung 2.3: Schematischer Aufbau einer SOAP-Nachricht. [5, S.79] Eine einfach gehaltene SOAP-Nachricht für einen Bestellvorgang ist in Abbildung 2.4 dargestellt und wird nachfolgend erläutert. Der SOAP-Envelope (Zeile 2) enth alt die eigentliche Nachricht und bildet das Wurzelelement des XML-Dokuments. Durch Angabe einer URI, z.b. wird der Namespace und die verwendete Version des SOAP-Standards definiert. Optional kann noch ein encodingstyle-attribut hinzugefügt werden, das angibt, wie der Body der Nachricht zu interpretieren ist. Unterhalb des Wurzelelements befinden sich ein bis zwei Kind-Elemente: der optionale SOAP-Header (Start Zeile 3) sowie der verpflichtende SOAP- Body (Start Zeile 17). Die möglichen Elemente im SOAP-Header sind nicht standardisiert und dienen daher der flexiblen Erweiterung der Nachricht. Der Header wird oft dazu verwendet, sicherheitstechnische Informationen zu ubermitteln, wie Abbildung 2.4 zeigt. In der Beispielnachricht wird in Zeile 4 die Rolle des Absenders definiert und in der n achsten Zeile angegeben, dass der Empf anger dieses Konzept auch verstehen muss (mustunderstand=true). Auf das in Zeile 7 übermittelte Security-Token wird im Kapitel zu WS-Trust noch genau Bezug genommen. Zeile zeigen binär kodierte Rechte. Wie diese zu interpretieren sind obliegt den kommunizierenden Anwendungen. Im SOAP-Body befinden sich die eigentlichen Nutzdaten. Der Body einer SOAP-Nachricht kann zum Beispiel aus einem (wohlgeformten, validen) HTML-Dokument bestehen. Die Interpretation des Inhalts obliegt weiterhin der Endanwendung.

14 KAPITEL 2. GRUNDLAGEN VON WEB SERVICES 9 1 <?xml version= 1. 0 encodi ng= u tf 8?> 2 <e n v :E n v el ope xmlns:env= h t t p : //www. w3. org /2003/05/ soap e nvelope > 3 <env:header> 4 <m : a u t h e n t i c a t i o n xmlns:m= h t t p : // example. com/ l o g i n 5 <e n v : r o l e= h t t p : // example. com/admin 6 <env:mustunderstand=t r u e > 7 <m : s e c u r i t y token>asdgawr8234gas8d234</ m : s e c u r i t y token> 8 </ a u t h e n t i c a t i o n> 9 <n : a u t h o r i z a t i o n xmlns:n= h t t p : // example. com/ l o g i n 10 <e n v : r o l e= h t t p : // example. com/admin 11 <env:mustunderstand=t r u e> 12 <n : r i g h t s> </n>r i g h t s > 15 </ a u t h o r i z a t i o n> 16 </ emv:header> 17 <env:body> 18 <o : o r d e r 19 e n v : e n c o d i n g S t y l e= h t t p : //www. w3. org /2003/05/ soap encod ing 20 xmlns:o= h t t p : //ws. example. com/ o r d e r / > 21 <o : n r> </ o : n r> 22 </ o : o r d e r> 23 </ env:body> 24 </ env :Env el ope> Abbildung 2.4: Beispiel einer SOAP-Nachricht mit Envelope, Header und Body. [5, S.80]

15 KAPITEL 2. GRUNDLAGEN VON WEB SERVICES RPC mit SOAP RPC (Remote Procedure Calls), das Aufrufen von auf entfernten Rechnern laufenden Diensten, ist nicht erst seit Service-orentierten Architekturen und Web Services bekannt. Definition 7 RPC sind eine Technologie zur Interprozesskommuniktion, die es erlauben, Routinen im Adressraum eines anderen Computers aufzurufen, ohne genauere Kenntnis uber die Lokalit at der Routine selbst zu besitzen. Ähnliche Möglichkeiten wie mit Web Services standen schon mit CORBA oder Java RMI zur Verf ugung, jedoch k onnen RPC-Calls auch mit SOAP verpackt und transportiert werden. CORBA (Common Object Request Broker Architecture) war die erste Technologie, die die Kommunikation zwischen in unterschiedlichen Programmiersprachen geschriebenen, auf unterschiedlichen Plattformen laufenden und verteilten Anwendungen erm oglichte. Uber Methoden-Stubs und dem Prinzip des (Un-)Marshalling (Verpacken/Entpacken der Anfragen/Antworten) kommuniziert eine Client-Anwendung mit dem Object Request Broker, der für die Weiterleitung des Requests an das richtige Server-Objekt sowie das Zurücksenden der Antwort an den Client verantwortlich ist. Java RMI (Remote Methode Invocation) ist eine ahnliche Technologie, fokusiert sich allerdings auf die Java Virtual Machines (JVMs). RMI erlaubt die Kommunikation von Anwendungen über die Grenzen verschiedener JVMs hinweg. F ur eine Java-Anwendung ist es somit m oglich, eine Methode eines Objekts aufzurufen, das sich auf einer anderen JVM befindet. RMI benutzt ebenfalls Methoden-Stubs für die Kommunikation und eine RMI Registry zum Auffinden der entfernten Objekte. Die Grundstruktur der SOAP-Nachricht bleibt auch bei einem RPC gleich. Die Spezifikation legt nur fest, dass das erste Kind-Element des SOAP-Body gleich heißen muss, wie die entfernt aufzurufende Methode. Auch die Antwort des Requests sieht sehr ahnlich aus, einzig die R uckga bewerte sind als rpc:result gekennzeichnet. Problematisch beim Aufruf von entfernten Methoden sind unterschiedliche Datentypen. SOAP versucht dieses Problem durch Metadaten zu umgehen. In der SOAP-Nachricht selbst wird beschrieben, welchen Datentyp ein Attribut hat. Um auf das Beispiel aus Abbildung 2.4 Bezug zu nehmen, wird <o:nr> </o:nr> zu <o:nr xsi:type="xsd:string"> </o:nr>

16 KAPITEL 2. GRUNDLAGEN VON WEB SERVICES 11 abgewandelt. Die SOAP-Spezifikation legt insgesamt 44 elementare Datentypen fest, die in einem Dokument zur Beschreibung der Typen verwendet werden k onnen. Komplexe Datentypen k onnen selbst mit Hilfe von structs bzw. arrays nachgerüstet werden. 2.3 WSDL WSDL (Web Service Describtion Language) stellt eine weitere Komponente zum Betrieb einer Web Services-Architektur dar. Definition 8 WSDL is an XML format for describing network services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information. 4 Um einen Dienst zu beschreiben stehen die in Abbildung 2.5 gezeigten Komponenten zur Verfügung. abstrakt konkret Describtion Operation MEP Interface Binding Endpoint Service Abbildung 2.5: Verfügbare WSDL-Komponenten. [5, S.108] Die einzelnen Komponenten der WSDL-Datei können am besten mit Hilfe eines Beispiels beschrieben werden: eine Taschenrechner-Anwendung stellt die grundlegenden Operationen Addieren, Subtrahieren, Multiplizieren und Dividieren als Web Service zur Verfügung. Die entsprechende WSDL-Datei ist in Abbildung 2.6 zu sehen. Da sich die zu implementierenden Operation kaum unterscheiden werden nur die relevanten Daten für die Operation Addieren gezeigt. Nach dem einleitenden Prolog folgt der types-teil. In diesem Fall werden die ausgetauschten Nachrichtentypen nicht in der WSDL-Datei sondern mit einer externen XML Schema-Datei deklariert und mit Hilfe des import- Statements eingebunden (Zeile 7-12). Abbildung 2.7 zeigt einen Ausschnitt der referenzierten Schema-Datei. 4 URL: Abgerufen am

17 KAPITEL 2. GRUNDLAGEN VON WEB SERVICES 12 1 <?xml version= 1. 0 encodi ng= UTF 8 standalone= yes?> 2 <d e f i n i t i o n s targetnamespace= h t t p : //cms. f h oo e. eu / 3 name= CalculatorW S S ervice x m l n s : t n s= h t t p : //cms. f h o o e. eu/ 4 xmlns:xsd= h t t p : //www. w3. org /2001/XMLSchema 5 xmln s:soap= h t t p : // schemas. xmlsoap. org / wsdl / soap / 6 xmlns= h t t p : // schemas. xmlsoap. org / wsdl / > 7 <t y pes> 8 <xsd:schema> 9 <x s d : i m p o r t namespace= h t t p : //cms. fh o o e. eu / 10 schemalocation= Calcul ator W SService s chema1. xsd /> 11 </ xsd:schema> 12 </ t y p es> 13 <message name= add > 14 <par t name= paramete rs element= t n s : a d d /> 15 </ message> 16 <message name= addresponse > 17 <par t name= paramete rs element= t n s:a d d R espo n se /> 18 </ message> 19 (... ) 20 <porttype name= CalculatorWS > 21 <o p e r a t i o n name= add > 22 <i nput message= t n s : a d d /> 23 <output message= tns: a d d R es p o n se /> 24 </ o p e r a t i o n> 25 (... ) 26 </ porttype> 27 <b i nd i n g name= CalculatorWSPortBinding type= t n s: C alculatorws > 28 <s o a p : b i n d i n g t r a n s p o r t= h t t p : // schemas. xmlsoap. org / soap / http /> 29 <o p e r a t i o n name= add > 30 <s o a p : o p e r a t i o n soapaction= /> 31 <i nput> 32 <soap:body use= l i t e r a l /> 33 </ i npu t> 34 <output> 35 <soap:body use= l i t e r a l /> 36 </ output> 37 </ o p e r a t i o n> 38 (... ) 39 </ b i n d in g> 40 <s e r v i c e name= Cal cula to rwsse rvi ce > 41 <por t name= CalculatorWSPort b i n d i n g= tns :Cal cula torw S Port Binding > 42 <s o a p : a d d r e s s l o c a t i o n= h t t p : //cms. f h o o e. eu / C a l c u l a t o r /> 43 </ por t> 44 </ s e r v i c e> 45 </ d e f i n i t i o n s> Abbildung 2.6: Ausschnitt einer WSDL-Datei für einen einfachen Taschenrechner-Web Service.

18 KAPITEL 2. GRUNDLAGEN VON WEB SERVICES 13 1 <?xml version= 1. 0 enc oding= UTF 8 standalone= yes?> 2 <xs:schema version= 1. 0 targetnamespace= h t t p : //cms. f h o o e. eu / 3 x m l n s : t n s= h t t p : //cms. f h o o e. eu / 4 x m l n s : x s= h t t p : //www. w3. org /2001/XMLSchema > 5 6 <x s : e l e m e n t name= add type= t n s : a d d /> 7 8 <x s : e l e m e n t name= addresponse type= t n s:a d d R espo n s e /> 9 (... ) 10 <xs:complextype name= add > 11 <x s : s e q u e n c e> 12 <x s : e l e m e n t name= i type= x s : d o u b l e /> 13 <x s : e l e m e n t name= j type= x s : d o u b l e /> 14 </ x s : s e q u e n c e> 15 </ xs:complextype> <xs:complextype name= addresponse > 18 <x s : s e q u e n c e> 19 <x s : e l e m e n t name= r e t u r n type= x s : d o u b l e /> 20 </ x s : s e q u e n c e> 21 </ xs:complextype> 22 (... ) Abbildung 2.7: Ausschnitt der referenzierten XML-Schema-Datei. In der referenzierten Datei werden die zwei verwendeten Datentypen beim Informationsaustausch definiert. Für die Anfrage an den Web Service wird der Typ add, für die Antwort addresponse verwendet. Beides sind komplexe, selbst definierte Datentypen. Der Typ add nimmt zwei Werte vom Typ double auf und addresponse liefert einen Double-Wert als Return- Value an den Aufrufer zurück. (vgl. Abbildung 2.7, Zeile 5-20) Im Abschnitt message aus Abbildung 2.6 werden in Zeile die ausgetauschten Nachrichten näher spezifiziert. Hier kommen die zuvor definierten Typen add bzw. addresponse wieder zum Einsatz. Der Abschnitt porttype (in neueren Versionen der WSDL interface) beschreibt die vorhandenen Operationen und welche Ein- und Ausgaben die Operation erwartet bzw. erzeugt. (Zeile 20-26) Im Bereich binding (Zeile 27/28) wird der Web Service an das HTTP- Protokoll gebunden und Informationen bereitgestellt, die für den Aufruf des Web Services notwendig sind. Abschließend wird im Abschnitt service (Zeile 40-44) beschrieben, wo sich der Web Service physikalisch befindet. Da der Endpoint, die Lokalität an dem sich der Service befindet, direkt in die Schnittstellenbeschreibung eingebettet ist, braucht ein Dienstenutzer keine darüber hinausgehenden Informationen um den Dienst nutzen zu können. In diesem service-abschnitt können, vor allem im Hinblick auf Fehlertoleranz und Redundanz, durchaus mehrere Endpunkte, d.h. mehrere

19 KAPITEL 2. GRUNDLAGEN VON WEB SERVICES 14 soap:addresses (Zeile 42), angegeben werden, die einen Service entsprechend der obigen Schnittstellendefinition zur Verfügung stellen. 2.4 Verzeichnisdienste Verzeichnisdienste stellen die dritte Komponente einer Web Services-Architektur dar. Verzeichnisdienste dienen in Unternehmen dazu, verschiedene Ressourcen (Benutzer, Dateien,...) auffindbar und Benutzern sowie Anwendungen gleichermaßen zugänglich zu machen. Durch den Einsatz von Verzeichnisdiensten wird innerhalb einer Web Service-Umgebung eine lose Koppelung der Dienste realisiert. Im Bereich Web Services gibt es im Moment zwei konkurrierende Herangehensweisen an die Thematik Verzeichnisdienste. Einerseits UDDI (Universal Description, Discoverty & Integration), wo viele Anbieter ihre Services in zentrale Repositories stellen, und andererseits der verteilte, dezentrale WS- Inspection-Standard mit der Web Services Inspection Language. Abbildung 2.8 stellt diese zwei Konzepte gegenüber. UDDI WS-Inspection Nutzer Nutzer suchen Dienste UDDI- Verzeichnis Anbieter Anbieter Anbieter veröffentlichen Dienste Anbieter Anbieter Anbieter Abbildung 2.8: Unterschiedliche Konzepte: UDDI und WS-Inspection. [5, S.135] Definition 9 UDDI ist ein hierarchisches Konzept, in der Anbieter die WSDL-Dokumente ihrer Web Services in Datenbanken eintragen und dann vom Verzeichnis der Offentlichkeit zugänglich gemacht werden. UDDI ist, analog zu DNS, hierarchisch aufgebaut. Das Wurzelelement bildet die URB (UDDI Business Registry), eine offentlich zug angliche Datenbank

20 KAPITEL 2. GRUNDLAGEN VON WEB SERVICES 15 im Internet. Aufgrund der hierarchischen Architektur unterscheidet UDDI drei Arten von Servern: Ein node unterstützt eine zumindest minimale Menge der im Standard definierten Funktionen. Eine registry besteht aus ein oder mehreren nodes und unterstützt den gesamten Funktionsumfang des UDDI-Standards. Affiliated Registries dienen zum gemeinsamen Verwenden von Daten zwischen verschiedenen UDDI-Verzeichnissen. Abbildung 2.9 zeigt die architektonischen Überlegungen beim Design von UDDI. Semi-private Registry UBR Node A Veröffentlichen Affiliated Private Registry Veröffentlichen Subscribe Replikation Veröffentlichen Affiliated Private Registry UBR Node B Private Registry Abbildung 2.9: UDDI-Architektur. [9, S.10] Das Ziel von UDDI ist es, dass Anwendungen dynamisch einen entsprechenden Ersatzdienst finden k onnen, wenn der prim are Service ausf allt. UD DI selbst besteht aus den zwei Kernkomponenten UDDI-XML-Schema sowie UDDI-API. Das UDDI-XML-Schema beschreibt das Datenmodel sowie die vorhandenen Datenstrukturen von UDDI.

21 KAPITEL 2. GRUNDLAGEN VON WEB SERVICES 16 Das UDDI-API ist als Web Service konzipiert, welcher Schnittstellen zum Suchen, Veröffentlichen und Verwalten von Daten im Verzeichnis bereitstellt. Ein UDDI-Verzeichnis selbst besteht nach [5, S.138f] aus vier Hauptentitäten: White Pages Yellow Pages Green Pages Service Type Registration In den White Pages k onnen Unternehmen Informationen uber sich selbst (nicht uber den Web Service) bereitstellen, sodass sich ein m oglicher Konsu ment einen Uberblick über den Anbieter verschaffen kann. Sollte der Name des anbietenden Unternehmens nicht bekannt sein, sehr wohl aber die Kategorie in der sich der Dienst befindet, werden die Yellow Pages verwendet. Beschreibungen zu einzelnen Diensten sind in den Green Pages hinterlegt und können auch dann noch gefunden werden, wenn weder Anbieter noch Kategorie bekannt sind. Die Green Pages beschreiben, wie auf einen Web Service zugegriffen werden kann. Das Gegenstück zu den Green Pages, die in menschenlesbarer Form vorliegen, ist die Service Type Registration, eine maschinenlesbare Form der Green Pages. Abbildung zeigt beispielhaft einen UDDI-Eintrag für einen Web Service von IBM. Der Abschnitt businessservice (Zeile 18-37) beschreibt den angebotenen Service. Mittels bindingtemplates (Zeile 23-36) wird beschrieben, wie und wo (accesspoint in Zeile 29/30) der Service angesprochen werden kann. Ein tmodel-eintrag (Zeile 31-34) beschreibt, welcher Spezifikation (z.b. WSDL) der Service entspricht. Neben UDDI existiert auch noch das WS-Inspection-Konzept, das versucht das Problem unzuverlässiger Suchergebnisse aufgrund nicht gewarteter, großer UDDI-Verzeichnise, durch Dezentralisierung und Trivialität zu umgehen. Die Möglichkeit, dass ein Anbieter sein eigenes Verzeichnis mit seinen eigenen Diensten betreibt ermöglicht in weiterer Folge auch eine verbesserte Suche für den Dienstenutzer, da dieser so z.b. nur bei Betreibern suchen kann, denen er auch vertraut. WS-Inspection [10] ist dokumentbasiert und stellt diese Dokumente über eine HTTP-Schnittstelle zur Verf ugung. Der Nutzer erh alt nach einer Suchan frage eine Liste der in diesem Verzeichnis registrierten Dienste und der jeweiligen WSDL-Dokumente um den Dienst auch nutzen zu können. Die WS Inspection-Spezifikation regelt neben dem Aufbau der WS-Inspection-Datei auch, wie eine solche Datei gefunden werden kann. 5 URL: Abgerufen am

22 KAPITEL 2. GRUNDLAGEN VON WEB SERVICES <b u s i n e s s E n t i t y businesskey= ba744ed0 3aaf 11d5 80dc c64 o p e r a t o r= www. ibm. com/ s e r v i c e s / uddi authorizedname= QS1 > <discoveryurls> <discoveryurl usetype= b u s i n e s s E n t i t y > h t t p : //www. ibm. com/ s e r v i c e s / uddi / uddiget? businesskey= BA744ED0 3AAF 11D5 80DC C64</ discoveryurl> </ discoveryurls> <name>xmethods</name> <d e s c r i p t i o n xml:lang= en >Web s e r v i c e s r e s o u r c e s i t e</ d e s c r i p t i o n> <c o n t a c t s> <c o n t a c t usetype= Founder > <personname>tony Hong</personName> <phone usetype= Founder /> < usetype= Founder >thong@xmethods. net</ > </ c o n t a c t> </ c o n t a c t s> <b u s i n e s s S e r v i c e s> <b u s i n e s s S e r v i c e servicekey= d e16 11d5 98bf c64 businesskey= ba744ed0 3aaf 11d5 80dc c64 > <name>xmethods Delayed Stock Quotes</name> <d e s c r i p t i o n xml:lang= en >20 minute delayed s t o c k quotes</ d e s c r i p t i o n> <bindingtemplates> <bindingtemplate bindingkey= d594a970 3e16 11d5 98bf c64 s ervi cekey= d e16 11d5 98bf c64 > <d e s c r i p t i o n xml:lang= en > SOAP binding f o r delayed s t o c k quotes s e r v i c e </ d e s c r i p t i o n> <a c c e s s P o i n t URLType= http >h t t p : // s e r v i c e s. xmethods. n e t : 8 0 / soap</ a c c e s s P o i n t> <t M o d e l I n s t a n c e D e t a i l s> <t M o d e l I n s t a n c e I n f o tmodelkey= uuid:0e727db0 3e14 11d5 98bf c64 /> </ t M o d e l I n s t a n c e D e t a i l s> </ bindingtemplate> </ bindingtemplates> </ b u s i n e s s S e r v i c e> </ b u s i n e s s S e r v i c e s> </ b u s i n e s s E n t i t y> Abbildung 2.10: Beispieleintrag für UDDI.

23 KAPITEL 2. GRUNDLAGEN VON WEB SERVICES 18 Ein solches Dokument besteht aus einem Inspection-Element mit beliebig vielen Service- oder Link-Elementen. Service-Elemente beinhalten die Definition von Diensten sowie deren technische Details, d.h. die URL unter der die WSDL-Datei für den Dienst gefunden werden kann. Link-Elemente verweisen hingegen auf externe Datenquellen wie weitere WS-Inspection- Dokumente oder ganze UDDI-Verzeichnisse. Ein einfaches WS-Inspection- Dokument mit dem Verweis auf ein WSDL-Dokument des Microsoft-UDDI- Services sowie einem Link auf ein weiteres WS-Inspection-Dokument ist in Abbildung 2.11 dargestellt. 1 <i n s p e c t i o n xmlns= h t t p : // schemas. xmlsoap. org /ws/2001/10/ i n s p e c t i o n / > 2 <s e r v i c e> 3 <d e s c r i b t i o n 4 referencednamespace= h t t p : // schemas. xmlsoap. org / wsdl / 5 l o c a t i o n= h t t p : // t e s t. uddi. m i c r o s o f t. com/ i n q u i r e. asmx?wsdl /> 6 </ s e r v i c e> 7 <l i n k 8 referencednamespace= h t t p : // schemas. xmlsoap. org /ws/2001/10/ i n s p e c t i o n / 9 l o c a t i o n= h t t p : //cms. fhooe. eu/ i n s p e c t i o n. w s i l /> 10 </ i n s p e c t i o n> Abbildung 2.11: WS-Inspection-Dokument mit Servicedefinition und weiterführendem Link. Um die Interoperabilität und Auffindbarkeit von WS-Inspection-Dokumenten zu gewährleisten, schreibt der Standard vor, dass das Dokument inspection.wsil heißen und im Wurzelverzeichnis des Webservers abrufbar sein muss. Obwohl Verzeichnisdienste ein wichtiges Konzept in einer Web Services- Architektur sind, haben sie, im Gegensatz zu den zuvor behandelten Technologien SOAP und WSDL, Akzeptanzprobleme. Besonders UDDI ist praktisch gesehen zu komplex, um in Firmen einen Mehrwert zu generieren. Es wird oft auch absichtlich auf die lose Koppelung verzichtet, da eine erhöhte Netzwerklast und verringerte Performance befürchtet werden. 2.5 Organisation & Geschäftsprozesse Im Gegensatz zu vielen klassichen IT-Landschaften orientiert sich eine von Web Services komponierte SOA stark an Geschäftsprozessen und deren Modellierung. Um die Flexibilit at sowie Integrationsm oglichkeiten in einem Un- ternehmen nutzen zu können, ist es von Vorteil, wenn auch die Organisationsform des Unternehmens Service-orientiert gestaltet ist. Über die Zeit sind die IT-Landschaften in Unternehmen meist unkoordiniert gewachsen. Die Folge dieses langjährigen Prozesses sind vertikale, d.h. an den IT-Systemen orientierte, IT-Landschaften. Diese Systeme funktionieren für sich alleine stehend gut, da sie sehr speziell auf eine Aufgabe ausge

24 KAPITEL 2. GRUNDLAGEN VON WEB SERVICES 19 richtet sind und diese gut erfüllen. Jedoch sind sie unflexibel und erschweren somit nicht nur die Einf uhrung einer SOA sondern generell Anderungen an Prozessen. Muss ein Gesamtprozess z.b. so abgeändert werden, dass sich die Flussrichtung (Reihenfolge wie einzelne Aufgaben erf ullt werden) andert, kann es schnell dazu kommen, dass Funktionen doppelt implementiert und Daten redundant gehalten werden. Eine solche vertikale IT-Landschaft ist in Abbildung 2.12 dargestellt. Ein Prozess durchläuft verschiedene Systeme, die jeweils eine eigene Möglichkeit zur Datenhaltung sowie eine eigene Benutzeroberfläche bieten. Ist der Teilprozess auf einem System fertig wird die Verarbeitung auf einem anderen System fortgesetzt, das wieder uber eine eigene Datenbank und GUI verfügt. GUI 1 GUI 2 GUI 3 Prozess Funktionen Daten Daten Daten Abbildung 2.12: Vertikal aufgestellte IT-Landschaft. [5, S.32] Im Gegensatz dazu orientieren sich horizontal aufgestellte IT-Landschaften (Abbildung 2.13) an den eigentlichen Prozessen. Die Teilaufgabe, die ein System bis dato zu erledigen hatte, wird in viele, kleinere Dienste unterteilt. Das IT-System bietet nach außen nur noch gewisse Dienste an, die zur Erfüllung eines gr oßeren Prozesses notwendig sind. Diese Dienste k onnen dann indivi duell kombiniert und zu neuen Prozessen zusammengefasst werden. Durch das Zusammensetzen (Komponieren) dieser Dienste zu einem größeren Ganzen soll ein Mehrwert erzeugt werden. Muss ein Prozess geändert werden, kann ein Dienst problemlos durch einen anderen ersetzt oder ein neuer Dienst eingeführt werden. Im Web Services-Umfeld gibt es mehrere M oglichkeiten, Gesch aftsprozes se zu modellieren und abzubilden. Vielversprechend ist BPEL4WS (Business Process Execution Language), da viele große Unternehmen (IBM, BEA, Adobe, Microsoft, JBoss, Oracle) diesen OASIS-Standard in ihren Produkten unterstützen [35]. BPEL4WS ist eine Auszeichnungssprache, um das Verhalten von auf Web Services basierenden Geschäftsprozessen zu beschreiben.

25 KAPITEL 2. GRUNDLAGEN VON WEB SERVICES 20 Eine (virtuelle) GUI Prozess Dienste System 1 System 2 System 3 Daten Abbildung 2.13: Horizontal aufgestellte IT-Landschaft. [5, S.33] Das Ziel ist es, Geschäftsprozesse, die mit externen Web Services mittels WSDL kommunizieren, zu beschreiben. Der Programmcode von BPEL4WS wird als XML-Dokument dargestellt und dient selbst wiederum als Eingabe in eine Workflow-Engine. Diese Workflow-Engine setzt das BPEL4WS-Dokument dann in z.b. C#-Code um und führt diesen aus. BPEL4WS baut auf den folgenden vier Standards auf [5, S.239]: XML Schema Bei BPEL4WS handelt es sich um ein XML-Dokument, das einem gewissen Schema entspricht. XPath wird genutzt, um verschiedene Knoten innerhalb des XML- Dokuments zu adressieren. WSDL Mit Hilfe von WSDL wird beschrieben, welche Dienste aus einer BPEL4WS-Anwendung heraus genutzt werden können. Außerdem ist ein mit BPEL4WS definierter Prozess selbst wieder ein Web Service und muss dementsprechend eine maschinenlesbare Schnittstellendefinition haben. WS-Addressing beschreibt die Service-Endpunkte der modellierten Prozesse. In einem BPEL4WS-Dokument werden einzelne Aktivitäten zu einem Geschäftsprozess zusammengefasst und dargestellt. Der BPEL4WS-Standard definiert Basis- und strukturierte Aktivit aten. Die am h aufigsten verwendete

26 KAPITEL 2. GRUNDLAGEN VON WEB SERVICES 21 Operation innerhalb der Basisaktivitäten ist die invoke-operation, mit der ein externer Web Service aufgerufen wird. (Abbildung 2.14) 1 <invoke name= C a l c u l a t e R e s u l t 2 p a r t n e r= mycalculator porttype= c a l c u l a t o r N S : C a l c u l a t o r 3 o p e r a t i o n= add 4 i n p u t V a r i a b l e= parameters outputvariable= r e s u l t > 5 </ invoke> Abbildung 2.14: Synchrone invoke-aktivit at in einem BPEL4WS Dokument. Die Kommunikation mit einem externen Service erfolgt mittels receive und reply. Receive ist Teil eines synchronen Aufrufes und blockiert daher so lange, bis ein entsprechender SOAP-Reply empfangen wird und verarbeitet werden kann. Neben dem Aufrufen von Web Services müssen oft Entscheidungen basierend auf den Rückgabewerten von externen Services getroffen werden. Dazu dienen Strukturierte Aktivitäten wie sequence, switch oder while. Diese steuern den Ablauf von anderen Basis- und strukturierten Aktivitäten. Flow beschreibt im Gegensatz zu den zuvor genannten Aktivitäten keinen sequentiellen Ablauf sondern den Fluss von parallelen bzw. synchronisiert ablaufenden Aktivitäten. Aktivit aten die sequentiell bzw. parallel abgearbeitet werden, werden in einen sequence- bzw. flow-block eingefasst wie Abbildung 2.15 zeigt. 1 <sequence> 2 <! a c t i v i t y 1 > 3 <! a c t i v i t y 2 > 4 </ sequence> 5 (... ) 6 <flow> 7 <invoke..> 8 </ invoke> 9 <sequence> 10 <r e c e i v e.. /> 11 <invoke..> 12 </ invoke> 13 </ sequence> 14 </ flow> Abbildung 2.15: Sequentielle bzw. parallele Definition von Aktivitäten aus einem BPEL4WS-Dokument. Das Resultat nach der Modellierung ist ein ausführbarer BPEL4WS Prozess, der unter Zuhilfenahme externer Web Services eine Aufgabe erfüllt und einen Mehrwert generiert. Der BPEL4WS-Prozess ist dabei selbst ein

27 KAPITEL 2. GRUNDLAGEN VON WEB SERVICES 22 Web Service und kann als solcher in weiteren, größeren BPEL4WS-Systemen eingesetzt werden.

28 Kapitel 3 Sicherheit von Web Services 3.1 WS-*-Familie Wie in der Einleitung dieser Arbeit auf Seite 1 erwähnt, entwickelt sich das Thema Sicherheit zu einem entscheidenden Aspekt für die Adaption von Web Services in Unternehmen. Als Folge dessen entwickelt die OASIS (Organization for the Advancement of Structured Information Standards) seit 2004 eine Familie von sicherheitsrelevanten Standards, die WS-*-Standards. OASIS beschreibt die Relevanz dieser Standards wie folgt: Delivering a technical foundation for implementing security functions such as integrity and confidentiality in messages implementing higher-level Web services applications. [11] Die WS-*-Familie deckt viele Einsatzgebiete und Fragestellungen beim Einsatz von Web Services ab, welche nachfolgend erläutert werden. Die Basis f ur darauf aufbauende Dienste stellt das in Kapitel 2.2 vorgestellte SOAP dar. Auf SOAP setzt WS-Security (WSS) auf, das mit Hilfe von XML-Signature und XML-Encryption (Kapitel 3.2) die Integrität und Vertraulichkeit von SOAP Nachrichten steigert. Zur Familie der WS-*-Standards gehören des Weiteren WS-Policy [12] und WS-Trust [14]. WS-Policy definiert, wie die Kommunikationspartner ihre Anforderungen an Kommunikationsparametern (beispielsweise Sprache und Zeichensatz) verbreiten und einfordern können. In weiterer Folge beschreibt WS- Trust ein Modell von Trust-Domains zwischen Third-Party-Providern und Intermediaries. Definition 10 Trust is the characteristic whereby one entity is willing to rely upon a second entity to execute a set of actions and/or to make a set of assertions about a set of principals and/or digital identities. [16, S.12] 23

29 KAPITEL 3. SICHERHEIT VON WEB SERVICES 24 Definition 11 A Trust Realm/Domain is an administered security space in which the source and target of a request can determine and agree whether particular sets of credentials from a source satisfy the relevant security policies of the target. [16, S.12] Definition 12 An Intermediary is a component that lies between the Service Client (subscriber) and the Service Provider (publisher). It basically intercepts the request from the Service Client, provides the service (functionality) and forwards the request to the Service Provider. Similarly, it intercepts the response from the Service Provider and forwards it to the Service Client. 1 Sowohl auf WS-Policy als auch auf WS-Trust wird im Anschluss an dieses Kapitel eingegangen. Ferner finden die Standards WS-SecureConversation [15] und WS-Federation [16] Einsatz bei Web Services. Ein WS-Authorization-Standard existiert zum Zeitpunkt dieser Arbeit noch nicht. WS-SecureConversation beschreibt, wie eine gegenseitige Authentifizierung bei Web Services umgesetzt werden kann. Diese Spezifikation zeigt, wie Session-, Derived- und Per-Message-Keys erstellt und sicher übertragen werden. Ferner erlaubt WS-SecureConversation mit Hilfe von WSS und WS-Trust den Austausch von Sicherheitskontexten mit allen damit verbundenen Attributen. Definition 13 A security context is an abstract concept that refers to an established authentication state and negotiated key(s) that may have additional security-related properties. [15] WS-Federation bietet zusätzlich zu WS-Trust eine Architektur zur klaren Unterscheidung zwischen Trust-Mechanismen, Security Token Formaten (X.509, Kerberos,...) und dem Protokoll zur Ubertragung der Security Tokens. [18, S.4] Definition 14 Ein Security Token ist im Allgemeinen ein physikalisches Objekt, welches zur Authentifizierung von Nutzern dient. Im Bereich von Web Services existieren mehrere (nicht-physikalische) Arten von Security Tokens, beispielsweise SAML security tokens oder X.509 Zertifikate. Je nach Kontext muss hier zwischen den unterschiedlichen Typen differenziert werden. 1 URL: Abgerufen am

30 KAPITEL 3. SICHERHEIT VON WEB SERVICES WS-Policy Standards und Policies helfen dabei, die Interoperabilität zwischen verschiedenen Anbietern und Diensten zu erhöhen. Definition 15 A policy is a collection of policy assertions. A policy assertion represents an individual requirement, capability, or other property of a behavior.[13] Wie Abbildung 3.1 zeigt kann eine Policy in weiterer Folge auch Einschr ankungen in Hinblick auf einzusetzende Algorithmen oder Schl ussell angen beinhalten. Teilnehmer A Policy anfordern Teilnehmer B Policy retournieren AES128 AES192 Eigene Policy AES192 AES256 AES128 AES192 AES192 Web Service Call mit AES192 Abbildung 3.1: Dynamisches Anpassen eines Funktionsaufrufes mittels Policy. [6, S.370ff] Teilnehmer A möchte einen Web Service von Teilnehmer B konsumieren. Dazu fragt Teilnehmer A zuerst die Policy von Teilnehmer B ab, welche die verfugbaren Algorithmen und Schlussell angen enth alt. Als n achsten Schritt vergleicht Teilnehmer A seine eigene Policy mit der von Teilnehmer B und berechnet daraus die effektive Policy. Definition 16 Eine effektive Policy ist das Resultat der Verknüpfung von zwei oder mehr Anforderungen verschiedenen Kommunikationsteilnehmer in Bezug auf Schl ussell angen und Algorithmen. Eine effektive Policy stellt einen kleinsten gemeinsamen Nenner zwischen den Kommunikationsteilnehmern dar. Dem Resultat der Berechnung entsprechend wählt Teilnehmer A daraufhin Schl ussell ange und Algorithmus aus.

31 KAPITEL 3. SICHERHEIT VON WEB SERVICES 26 Im Beispiel bedeutet das, dass sich die Teilnehmer auf AES als Algorithmus und eine Schl ussell ange von 192 Bit einigen. Teilnehmer A passt seinen Funktionsaufruf nun dynamisch an die vereinbarten Werte an. Die WS-Policy-Spezifikation [13] definiert eine syntaktische Beschreibung zur Erstellung von Policies sowie Algorithmen zur Berechnung der effektiven Policy. Eine mit WS-Policy beschriebene Policy ist, analog zur auf Seite 41 vorgestellten SAML, eine Ansammlung von assertions (Behauptungen). Abbildung 3.2 zeigt den Aufbau einer solchen Policy mit zwei Assertions. 1 <w s p : P o l i c y 2 xm l n s:s p= h t t p : // docs. o a s i s open. org /ws sx /ws s e c u r i t y p o l i c y / xmlns:wsp= h t t p : //www. w3. org / ns /ws p o l i c y > 4 <wsp:exactlyone> 5 <w s p : a l l> 6 <wsp:language Language= en /> 7 <wsp:textencoding Encoding= UTF 8 /> 8 </ w s p : a l l> 9 <w s p : a l l> 10 <wsp:language Language= de /> 11 <wsp:textencoding Encoding= i s o l a t i n 1 /> 12 </ w s p : a l l> 13 </ wsp:exactlyone> 14 </ w s : P o l i c y> Abbildung 3.2: Aufbau einer WS-Policy-Richtlinie. Der Prolog in den ersten drei Zeilen umfasst die Definition, dass es sich sich um eine WS-Policy handelt und gegen welches Schema die Datei validiert wird. Mit ExactlyOne in Zeile 4 wird festgelegt, dass genau eine der nachfolgend aufgef uhrten M oglichkeiten verwendet werden muss. Mit wsp:all wird spezifiziert, dass beide nachfolgend genannten Bedingungen erfüllt werden m ussen. Im Beispiel ist es somit m oglich, einen fiktiven Web Service ent weder mit Englisch als Sprache und UTF-8 als Zeichensatz oder mit Sprache Deutsch und Zeichensatz ISO-Latin-1 aufzurufen. Neben den genannten ExactylOne und All existiert die Möglichkeit, mit einer URI auf eine externe Policy (PolicyReference) zu verweisen. WS-Policy enthält nur sehr fundermentale Assertions, wie die gesehenen Language oder Encoding. Sicherheitsrelevante Assertions sind in der WS SecurityPolicy-Spezifikation definiert. WS-SecurityPolicy WS-SecurityPolicy [12] basiert auf der auf Seite 25 vorgestellten WS-Policy- Spezifikation [13] und definiert einen standardisierten Weg, um sicherheitsrelevante Anforderungen bei einer Kommunikation in einer standardisierten

32 KAPITEL 3. SICHERHEIT VON WEB SERVICES 27 Form zu beschreiben. Durch die Definition und Veröffentlichung dieser Anforderungen wird eine Applikation zum Einhalten gewisser, in der Policy definierter, Algorithmen und Schl ussell angen gezwungen, sodass die gefor derten Sicherheitsparameter sichergestellt werden können. Analog zu den Assertions von WS-Policy bilden Assertions auch bei WS-SecurityPolicy die Basis, um die Anforderungen umzusetzen. Die WS-SecurityPolicy-Spezifikation unterscheidet vier Typen von Assertions: Protection assertions Token assertions Supporting token assertions Security binding assertions Die Gruppe der Protection assertions definiert, welche Nachrichtenteile besonders gesch utzt (signiert bzw. verschl usselt) werden und bis zu welchem Level. Die Integrity assertions geben an, welche Teile (SignedParts) oder Elemente (SignedElements) in einem Dokument signiert werden müssen. Auf Seite der Confidentiality assertions dienen die Assertions EncryptedParts bzw. EncryptedElements zur Beschreibung, dass die Vertraulichkeit dieser Teile oder Elemente durch Verschlüsselung sichergestellt werden muss. Abbildung 3.3 zeigt, wie diese Assertions angewendet und in einen WS-Policy- Tag eingeschlossen werden. Im Beispiel müssen sowohl Body als auch Header der SOAP-Nachricht signiert (Zeile 4-7) und der Body der Nachricht zusätzlich auch noch verschlüsselt (Zeile 8-10) werden. 1 <w s p : P o l i c y 2 xm l n s:s p= h t t p : // docs. o a s i s open. org /ws sx /ws s e c u r i t y p o l i c y / xmlns:wsp= h t t p : //www. w3. org / ns /ws p o l i c y > 4 <s p : S i g n e d P a r t s> 5 <sp:body /> 6 <sp:heade r /> 7 </ s p : S i g n e d P a r t s> 8 <s p : E ncr y p t e d Pa r t s> 9 <sp:body /> 10 </ s p : E n cry p t e dpa r ts> 11 </ w s : P o l i c y> Abbildung 3.3: Einsatz von Protection assertions. Mit Hilfe von Token assertions ist es möglich anzugeben, welche Arten von Security Tokens ein Client verstehen muss, um mit dem Web Service kommunizieren zu können. Beispielsweise kann ein Web Service in einer entsprechenden Policy formulieren, dass der Client in der Lage sein muss, in

33 KAPITEL 3. SICHERHEIT VON WEB SERVICES 28 die Nachrichten eingebettete X.509-Tokens zu verstehen. Ausgedrückt kann diese Forderung wie in Abbildung 3.4 werden. Wss11 gibt dabei an, um welche Referenzspezifikation es sich handelt. 1 <sp:wss11> 2 <w s : P o l i c y> 3 <sp:mustsupportrefembeddedtoken /> 4 </ w s : P o l i c y> 5 </ sp:wss11> Abbildung 3.4: Einsatz von Token assertions. Security binding assertions spezifizieren die Grundlagen der gesicherten Kommunikation. Dazu geh oren neben den eingesetzten Schl usseln auch Schl ussell angen und Algorithmen. Das auf Seite 25 illustrierte Beispiel ist auf Security Binding Assertions angewiesen, um das dargestellte Szenario zu lösen WS-Trust WS-Trust [14] baut auf den von WSS eingeführten Sicherheitsmechanismen auf und erweitert diese um Möglichkeiten zur Etablierung von Trust- Relationships. Um eine Kommunikation zwischen mehreren Partner abzusichern, müssen die Kommunikationspartner Security-Credentials austauschen. Die Teilnehmer müssen entscheiden, ob sie den angebotenen Credentials vertrauen und diese akzeptieren. Dazu definiert WS-Trust Mechanismen, um Security-Tokens auszustellen, zu erneuern und zu validieren. Um Security-Tokens auszustellen bietet WS-Trust das Security Token Service Framework (STS). Möchte ein Client beispielsweise einen Web Service aufrufen, fordert der Client ein Security-Token vom STS an, um genau diesen Service benutzen zu können. Dazu verwendet der Client eine SOAP- Nachricht mit einem RequestSecurityToken-Element. Nach einer erfolgreichen Authentifizierung sendet der STS dem Client ein Security Token, zum Beispiel eine SAML assertion (siehe Kapitel 3.3) oder ein Kerberos-Ticket, als RequestSecurityTokenResponse zurück. Mit diesem RequestSecurityTokenResponse weist sich der Client nun gegenüber dem Web Service aus. Nachfolgend wird exemplarisch das Ausstellen eines neuen Security-Tokens beschrieben. Abbildung 3.5 aus [14] zeigt die Struktur eines RequestSecurityToken- Elements (RST). Das TokenType-Element in Zeile 2-4 spezifiziert den Typ des Security-Tokens das der Client erwartet. Im Beispiel wird die URI zum Kerberos Token Profile angegeben. RequestType (Zeile 6) beschreibt, 2 URL:

34 KAPITEL 3. SICHERHEIT VON WEB SERVICES 29 1 <w st : R e q u e st Se c u rit y T o k e n xmlns:wst=... > 2 <wst:tokentype> 3 h t t p : // docs. o a s i s open. org / wss / o a s i s wss k erb e r o s token p r o f i l e </ wst:tokentype> 5 <wst:requesttype> 6 h t t p : // schemas. xmlsoap. org /ws /2005/02/ t r u s t / I s s u e 7 </ wst:requesttype> 8 <wsp:appliesto>... </ wsp:appliesto> 9 <wst :Clai ms D i a l e c t=... >... </ w s t : C laim s> 10 <wst:entropy> 11 <w s t : B i n a r y S e c r e t>... </ w s t : B i n a r y S e c r e t> 12 </ wst:entropy> 13 <w s t : L i f e t i m e> 14 <wsu:created>... </ wsu:created> 15 <wsu : E xp i r e s>... </ w s u :Ex pi res> 16 </ w s t : L i f e t i m e> 17 </ w st : R e q u e st Se c u rit y T o k e n> Abbildung 3.5: Struktur des RequestSecurityToken-Elements. ob es sich um eine Neuaustellung, Verlängerung oder Validierung handelt, in Beispiel 3.5 wird ein neues Token ausgestellt (Issue). Das AppliesTo- Element spezifiziert den aufzurufenden Web Service, für welchen das Token bestimmt ist, und enthält eine Referenz auf diesen. Der STS kann daher sein eigenes Wissen über den Service nutzen, um das Token auf den Service abzustimmen. Als nächstes werden die Claims (Anforderungen) formuliert, in welchen der Client angeben kann, dass der STS zum Beispiel ein SAML authentication statement ausstellen soll. Zum Formulieren der Claims benötigt WS-Trust das im vorigen Kapitel vorgestellte WS-SecurityPolicy. Optional ist das Entropy-Element (Zeile 10-12), welches die Ubermittlung eines Zufallswertes oder Schlüssels an den STS erlaubt. Nach dem Request versucht der STS, die Identit at des Anfragers zu verifizieren und sendet bei Erfolg ein RequestSecurityTokenResponse (RSTS), ahnlich wie in Abbildung 3.6, zur uck. Kann die Identit at des Aufrufers nicht sichergestellt werden, wird ein SOAP Fault gesendet. Die Elemente TokenType und AppliesTo werden unverändert an den Aufrufer zur uckgesendet. Das RequestedSecurityToken enth alt das angeforderte Security-Token. Das kann beispielsweise eine signierte und verschlüsselte SAML assertion oder ein signiertes, verschlüsseltes Kerberos-Ticket sein. RequestedAttachedReference bzw. RequestedUnattachedRefernce beinhalten eine Referenz auf das Security-Token um es in anderen Dokumenten zu verwenden. WS-Trust bildet die Basis, um Identity Federation umzusetzen. Um die eigentliche Umsetzung kümmert sich aber die WS-Federation-Spezifikation. os-kerberostokenprofile.pdf. Aberufen am

35 KAPITEL 3. SICHERHEIT VON WEB SERVICES <wst:requestsecuritytokenresponse xmlns:wst=... > <wst:tokentype> h t t p : // docs. o a s i s open. org /wss/ o a s i s wss kerberos token p r o f i l e 1.1 </ wst:tokentype> <wst:requestedsecuritytoken> <wsse:binarysecuritytoken ValueType=... / o a s i s wss 224 kerberos token p r o f i l e 1.1#Kerberosv5 AP REQ wsu:id= MyToken > boibxdccaccgawibbaeda226 </ wsse:binarysecuritytoken>227 </ wst:requestedsecuritytoken> <wsp:appliesto xmlns:wsp=...? >... < / wsp:appliesto> <wst:requestedattachedreference >... </wst:requestedattachedreference > <wst:requestedunattachedreference >... </wst:requestedunattachedreference > <wst:requestedprooftoken >... </ wst:requestedprooftoken> <wst:entropy> <w s t :BinarySecret >... </ wst:binarysecret > </wst:entropy> <w s t : L i f e t i m e >... </ w s t : L i f e t i m e > </wst:requestsecuritytokenresponse > Abbildung 3.6: Struktur des RequestSecurityTokenResponse-Elements.

36 KAPITEL 3. SICHERHEIT VON WEB SERVICES 31 WS-Federation WS-Federation [16] erweitert WS-Trust um Mechanismen zur Identity Federation. Definition 17 Identity federation allows partnering organizations to trust and share digital identities and attributes of employees, customers, and suppliers across domains, andtoprovide single sign-on across partner sites. 3 Verschiedene Security-Domains haben eine Trust-Relationship zum sicheren Austausch von Ressourcen etabliert. Definition 18 Eine Security-Domain ist eine Umgebung oder ein Kontext der durch gewissen Eigenschaften und einem zu Grunde liegenden Security- Modell definiert ist. Ein Ressourcen-Anbieter A kann einem Client C ein Security-Token für Ressourcen von Anbieter B ausstellen, sofern zwischen Anbieter B und Anbieter A eine Trust-Relationship besteht. Beispielsweise kann ein Flugzeugpassagier gleichzeitig auch Hotelgast sein. Wenn die Fluglinie und die Hotelkette Teil einer Trust-Relationship sind, muss sich der Reisende nur gegenüber einem der Systeme authentifizieren, kann jedoch beide mit der gleichen Identität benutzen. Das Ziel von WS-Federation ist die vereinfachte Implementierung von verteilten Diensten durch domainübergreifende Kommunikation und Management. Dazu wird das in WS-Trust eingeführte Security-Token-Model wiederverwendet. Basierend auf diesem Model erweitert WS-Federation die WS-Trust-Spezifikation um spezifische Anwendungsszenarien, beispielsweise zur Authorisierung. WS-Federation beschreibt in [16, S.7ff] verschiedene Modelle, wie eine Trust-Relationship aussehen kann. An dieser Stelle sollen zwei Beispiele die M oglichkeiten zum Einsatz von WS-Federation erl autern. Abbildung 3.7 zeigt ein typisches Szenario für Identity Federation. 1. Der Requestor möchte auf eine Ressource in einer anderen Security- Domain zugreifen. Im ersten Schritt erstellt der STS des Requestors ein Security-Token zum Zugriff auf die Ressource in der zweiten Security- Domain. 2. Mit diesem Security-Token ausgestattet greift der Requestor nun auf die Ressource zu. 3. Im dritten Schritt leitet der Ressourcenanbieter das vom Requestor empfangene Security-Token zur Validierung an den eigenen STS weiter. 3 URL: id federation.pdf. Abgerufen am

37 KAPITEL 3. SICHERHEIT VON WEB SERVICES 32 Abbildung 3.7: Betrachtung eines möglichen Trust-Szenarios. [16, S.8] Da zwischen den STS der beiden Security-Domains eine Trust-Relationship aufgebaut wurde, erkl art der zweite STS das Security-Token f ur g ultig und der Requestor kann auf Ressourcen in der fremden Security-Domain zugreifen. Best unde diese Trust-Relationship nicht, w are das Security-Token ung ultig und der Zugriff w urde verweigert werden. Ein weiteres Einsatzszenario beschreibt Abbildung 3.8. Neben der vorgestellten Möglichkeit als Access Token Provider ist auch der Einsatz als Identity Provider (IP) möglich. Abbildung 3.8: Trust-Szenario als Identity Provider. [16, S.12] 1. Im ersten Schritt sendet der Requestor eine Anfrage an den Identity Provider, der ihm daraufhin einen identity security token ausstellt.

38 KAPITEL 3. SICHERHEIT VON WEB SERVICES Dieses Token sendet der Requestor nun an den STS. Da zwischen STS und IP eine Trust-Relationship besteht, stellt der STS dem Requestor ein access security token aus. 3. Das neue Token verwendet der Requestor nun, um auf die gewünschte Ressource zuzugreifen. 3.2 XML-Sicherheit Wie aus den vorangegangenen Kapiteln hervorgeht, bilden verschiedene XMLbasierte Technologien die Basis für Web Services und deren Sicherheit. Um die Integrit at und Vertraulichkeit der mit Web Services ubertragenen Daten zu erhöhen werden die beiden Spezifikationen XML-Signature und XML- Encryption eingesetzt. Mit Hilfe von XML-Signature und XML-Encryption ist es möglich, neben einem gesamten Dokument nur Teilbäume oder einzelne Attribute zu signieren bzw. zu verschlüsseln. Damit kann zwischen sicherheitsrelevanten Abschnitten, welche verschl usselt werden, sowie offentlichen Informationen, die keiner Verschl usselung bed urfen, unterschieden werden XML-Signature Um die Integrität eines versendeten XML-Dokuments sowie dessen Herkunft sicherstellen zu können, muss das übertragene XML-Dokument (oder Teile davon) digital signiert werden. Im Bereich XML existiert hierzu der XML- Signature-Standard (XML-DSig) [19]. XML-DSig ist nicht auf den Einsatz in Web Services beschränkt sondern kann generell auf digitale Inhalte verschiedenster Formate angewendet werden. XML-DSig führt keine neuen kryptographischen Konzepte ein, sondern stellt ein Regelwerk zur Erstellung und Repräsentation von XML-basierten Signaturen dar. Die Erstellung einer XML-Signatur l auft in zwei Schritten ab: 1. Das XML-Dokument wird durch Kanonisierung in einen normalisierten Zustand uberf uhrt. Definition 19 Durch Kanonisierung (engl. canonicalization, kurz C14N) werden syntaktische Unterschiede (unterschiedliche Zeichensätze, Zeilenumbrüche, leere Tags und die Reihenfolge der Attribute innerhalb eines Tags) von ansonsten semantisch gleichen Dokumenten ausgeglichen und somit in eine einheitliche Darstellung uberf uhrt. 4 4 Eine ausf Beschreibung der XML-Kanoniserung findet sich unter URL: uhrliche Abgerufen am

39 KAPITEL 3. SICHERHEIT VON WEB SERVICES Die kanonisierte Version wird als Eingabe in eine Hashfunktion verwendet und deren Ausgabe in Form eines Hashwertes abschließend mit dem privaten Schlüssel des Absenders signiert. XML-DSig spezifiziert drei verschiedene Arten (vgl. Abbildung 3.9) von Signaturtypen: Abbildung 3.9: Drei verschiedene Arten von XML-Signaturen. Enveloped Die Signatur ist Teil des zu signierenden Dokuments. Enveloping Bei dieser Version sind die eigentlichen Nutzdaten Teil der Signatur. Detached Beim Einsatz von Detached Signatures besteht keine Eltern Kind-Beziehung zwischen der Signatur und den zu signierenden Daten. Stattdessen werden beide als autonome Ressourcen betrachtet Die XML-Signatur wird im SOAP-Header, gekapselt in ein Security- Element (Abbildung 3.10, Start/Ende Zeile 3/20), übertragen. Wie Abbildung 3.10 zeigt (Zeile 9-19), besteht eine XML-Signatur aus den drei Elementen: SignedInfo, SignatureValue und KeyInfo Das umschließende Signature-Element beinhaltet die Information, welche Elemente unterschrieben werden, wie sie unterschrieben werden sowie den Wert der Signatur. SignedInfo enthält Referenzen auf die Daten, welche in die Signaturberechnung einfließen. Im Beispiel soll der gesamte Body der Nachricht signiert werden. Um auf dieses Element Bezug nehmen zu können wurde diesem Element in Zeile 22 der Anker Signed-Body zugewiesen. Abbildung 3.11 [6, S.280] zeigt das SignedInfo-Element im Detail. Bei der Signaturerstellung

40 KAPITEL 3. SICHERHEIT VON WEB SERVICES 35 1 <e n v :E n v el ope xmlns:env= h t t p : //www. w3. org /2003/05/ soap / e n v e l o p e / > 2 <env:header> 3 <w s s e : S e c u r i t y> 4 <w s s e : B i n a r y S e cu r i t y T ok e n 5 ValueType=... # X509PKIPathv1 6 EncodingType=... # Base64Binary 7 wsu: Id= S i g nat u r e X509 Key > 8 </ w s s e : B i n a r y S e c u r i t y To k e n> 9 <d s : S i g n a t u r e> 10 <d s : S i g n e d I n f o> 11 (... ) 12 </ d s : S i g n e d I n f o> 13 <d s : S i g n a t u r e V a l u e> 14 Q7NOiNfrDhY3XzD+AB9Sl4lu56glD2OAow07RJRuElbz8Gu+fJFUIA== 15 </ d s : S i g n a t u r e V a l u e> 16 <d s : K e y I n f o> 17 (... ) 18 </ d s : K e y i n f o> 19 </ d s : S i g n a t u r e> 20 </ w s s e : S e c u r i t y> 21 </ env:header> 22 <env:body wsu:id= Signed Body > 23 (... ) 24 </ env:body> 25 </ env :Env el ope> Abbildung 3.10: Aufbau einer XML-Signatur und Einbindung in einen SOAP-Request.

41 KAPITEL 3. SICHERHEIT VON WEB SERVICES 36 werden die URIs aller Reference-Elemente aufgelöst und die dort hinterlegten Daten mit dem im Transforms-Element angegebenen Verfahren transformiert. Danach werden die entstandenen Daten normalisiert und mit der unter DigestMethod angegebenen Methode ein Hashwert gebildet und unter DigestValue abgelegt. Dieser Vorgang wiederholt sich für jedes Reference- Element. 1 <d s : S i g n e d I n f o> 2 <ds:canonicalizationmethod 3 Algorithm= h t t p : //www. w3. org /2001/10/xml exc c14n# /> 4 <ds:signaturemethod 5 Algorithm= h t t p : //www. w3. org /2000/09/ xmldsig#dsa sha1 /> 6 <d s : R e f e r e n c e URI= #Signed Body > 7 <ds:transforms> 8 <ds:transform Algorithm=... / REC xml c14n /> 9 </ ds:transforms> 10 <ds:digestmethod 11 Algorithm= h t t p : //www. w3. org /2000/09/ xmldsig#sha1 /> 12 <d s : D i g e s t V a l u e>qs/ydsg/jsrug4zlj9ixpqhiipi=</ d s : D i g e s t V a l u e> 13 </ d s : R e f e r e n c e> 14 </ d s : S i g n e d I n f o> Abbildung 3.11: SignedInfo-Element. Das gesamte SignedInfo-Element wird dann gemäß dem unter CanonicalizationMethod angegebenen Algorithmus in eine kanonisierte Version uberf uhrt. Die kanonisierte Version dient wieder als Eingabe in die in Si gnaturemethod definierte Funktion, welche den resultierenden Hashwert im SignatureValue-Element abspeichert. Dieses SignatureValue-Element wird schließlich mit dem privaten Schlüssel des Absenders signiert. Das KeyInfo-Element gibt an, wo der zur Signierung verwendete Schlüssel gefunden werden kann. Hier kann sowohl auf ein SecurityTokenReference- Element verwiesen (vgl. Abbildung 3.10, Zeile 4-8) als auch die Schlüsselnformationen direkt eingebettet werden, wie Abbildung 3.12, wo ein X.509 Zertifikat direkt eingebunden wird, zeigt. Der Verifikationsprozess auf Seite des Empf angers l auft in zwei Phasen ab, die nach [19] als Reference- bzw. Signature Validation bezeichnet werden. 1. In der Reference Validation muss das SignedInfo-Element unter Berücksichtigung der richtigen Methode normalisiert werden. Für jedes Reference- Element muss das Objekt entsprechend transformiert und das Digest- Value unter Zuhilfenahme der richtigen DigestMethod berechnet werden. Die Validierung schlägt fehl, sobald das generierte Digest nicht mit dem DigestValue im SignedInfo-Block übereinstimmt. 2. Der Signature Validation Prozess umfasst das Aufbereiten der Infor

42 KAPITEL 3. SICHERHEIT VON WEB SERVICES 37 1 <d s : K e y I n f o> 2 <ds:x509data> 3 <d s : X C e r t i f i c a t e> 4 MIIDbzCCAy0CBElDn54wCwYHKoZIzjgEAwUAMIG 5 cmqswcqydvqqgewjbvdeymbyga1uecbmpt 6 2Jlcm9lc3RlcnJlaWNoMRIwEAYDVQQHEwlIYWdlb 7 (... ) 8 OEWOAsLk6jQd0wdsk/CG4rzGrsXUFeswCwYHKo 9 EOLdEmFGAhQIeBX/o8FubL/yzCcs9LvI1CWbNQ= 10 </ d s : X C e r t i f i c a t e> 11 </ ds:x509data> 12 <ds:keyvalue> 13 <ds:dsakeyvalue> 14 <ds:p> 15 / X9TgR11EilS30qcLuzk5 /YRt1I870QAwx4/gLZRJm 16 K2HXKu/yIgMZndFIAcc= 17 </ ds:p> 18 <ds:q>l2bqjxujc8yykrmcouuec/byhpu=</ ds:q> 19 </ds:dsakeyvalue> 20 </ ds:keyvalue> 21 </ d s : K e y I n f o> Abbildung 3.12: KeyInfo-Element. mationen aus dem KeyInfo-Feld um mit diesen Informationen das SignatureValue-Feld im Signature-Block zu validieren. Dazu muss als erstes der Schl ussel gem aß den Informationen im KeyInfo-Feld besorgt werden. Daraufhin wird das SignedInfo-Feld in seine kanonisierte Form gebracht und als Eingabe für die Hashfunktion verwendet. Abschließend wird der resultierende Hashwert noch mit dem entschlüsselten Hashwert der Signatur verglichen und die Signatur für valide oder falsch erklärt XML-Encryption Neben der Integrität und Non-Repudiation muss auch die Vertraulichkeit von Nachrichten bei der Ubertragung sichergestellt werden. Definition 20 Non-Repudiation (Nicht-Leugenbarkeit) heißt, dass ein Vertragspartner eine getätigte Aussage weder zurücknehmen noch leugnen kann. Auf dem Transport-Layer kann, wie bei vielen anderen Protokollen auch, TLS/SSL eine Point-to-Point-Sicherheit bieten. Der XML-Encryption-Standard [20] bietet zus atzlich folgende M oglichkeiten [6, S.237]: Selektive Verschl usselung Mit TLS kann nur die gesamte Ubert ragung zwischen zwei Parteien gesichert werden. SOAP-Nachrichten können allerdings, beispielsweise im Zuge einer Online-Transaktion,

43 KAPITEL 3. SICHERHEIT VON WEB SERVICES 38 mehrere SOAP Nodes passieren, welche ihrerseits individuelle Teile des XML-Dokuments für verschiedene Kunden signieren bzw. verschl usseln m ussen. Erhaltung der XML-Syntax Auch nach dem Verschlüsseln muss zumindest der SOAP-Envelop weiterhin ein valides, well-formed XML- Dokument darstellen. Definition 21 A textual object is a well-formed XML document if, taken as a whole, it matches the production labeled document. It meets all the well-formedness constraints given in this specification. Each of the parsed entities which is referenced directly or indirectly within the document is well-formed. 5 Metadaten Da es durch die selektive Verschl usselung m oglich ist, nur Teile eines Dokuments zu verschl usseln, muss es einen standardisierten Weg geben, um anzuzeigen wie und welche Teile verschlüsselt wurden. Dazu dienen XML-Elemente und -Attribute in den SOAP- Nachrichten. Der XML-Encryption-Standard gibt Regeln vor, wie Verschlüsselung auf XML-basierte Daten (der Standard ist nicht auf SOAP beschränkt) angewendet wird. XML-Encryption ersetzt TLS nicht, sondern bietet die Möglichkeit, zusätzliche Anforderungen der XML-Sicherheit, welche von TLS nicht abgedeckt werden, zu erfüllen. Neben der Verschl usselung des gesamten Dokuments bietet XML-Encryption die M oglichkeit, nur Teilknoten oder Nutzdaten zu verschl usseln. Das in Abbildung 3.13 dargestellte Dokument enthält sensible Kreditkarteninformationen und soll daher vor der Ubertragung verschlüsselt werden. Die erste Möglichkeit besteht darin, das gesamte Dokument zu verschl usseln. Abbildung 3.14 zeigt das Resultat einer solchen Verschl usselung. Abbildung 3.15 zeigt das Resultat der Verschl usselung, wenn diese nur auf das sensible Payment-Element angewandt wird. In den meisten Fällen ist es ausreichend, diese Informationen vertraulich zu behandeln sofern ein Angreifer kein Interesse an den gekauften Artikeln hegt. Die gekauften Artikel werden im Klartext ubertragen. Im Gegensatz zu dritten M oglichkeit (Abbildung 3.16), wo nur die Kreditkartennummer verschlüsselt wird, kann ein möglicher Angreifer gar nicht erst erkennen, um welche Art von Informationen es sich handelt. Voraussetzung um Dokumente oder Elemente verschl usseln zu k onnen sind entsprechende Schl ussel. Der Austausch der Schl ussel erfolgt bei XML Encryption mit dem KeyInfo-Element. Abbildung 3.17 zeigt die beiden relevanten Nachrichten. Im ersten Schritt sendet der erste Teilnehmer seinen 5 URL: Abgerufen am

44 KAPITEL 3. SICHERHEIT VON WEB SERVICES 39 1 <purchaseorder> 2 <Order> 3 <Item>Wer bin i c h und wenn ja, w i e v i e l e?</ Item> 4 <Isb n> </ Isbn> 5 <Quantity>2</ Quantity> 6 </ Order> 7 <Payment> 8 <CardId> </ CardId> 9 <CardName>Mastercard</CardName> 10 <ValidDate> </ ValidDate> 11 </Payment> 12 </ purchaseorder> Abbildung 3.13: XML-Dokument mit sensiblen Kreditkarten-Informationen. 1 <EncryptedData xmlns= h t t p : //www. w3. org /2001/04/ xmlenc# 2 MimeType= t e x t /xml > 3 <EncryptionMethod 4 Algorithm= h t t p : //www. w3. org /2001/04/ xmlenc#t r i p l e d e s cbc /> 5 <CipherData> 6 <CipherValue>A23B45C56</ CipherValue> 7 </ CipherData> 8 </ EncryptedData> Abbildung 3.14: Vollst andig verschl usseltes XML-Dokument. 1 <purchaseorder> 2 <Order> 3 <Item>Wer bin i c h und wenn ja, w i e v i e l e?</ Item> 4 <Isbn> </ Isbn> 5 <Quantity>2</ Quantity> 6 </ Order> 7 <EncryptedData Type= h t t p : //www. w3. org /2001/04/ xmlenc#element 8 xmlns= h t t p : //www. w3. org /2001/04/ xmlenc# > 9 <EncryptionMethod 10 Algorithm= h t t p : //www. w3. org /2001/04/ xmlenc#t r i p l e d e s cbc /> 11 <CipherData> 12 <CipherValue>A23B45C564587</ CipherValue> 13 </ CipherData> 14 </ EncryptedData> 15 </ PurchaseOrder> Abbildung 3.15: Verschlüsseltes Payment-Element.

45 KAPITEL 3. SICHERHEIT VON WEB SERVICES 40 1 <purchaseorder> 2 <Order> 3 <Item>Wer bin i c h und wenn ja, w i e v i e l e?</ Item> 4 <Isb n> </ Isbn> 5 <Quantity>2</ Quantity> 6 </ Order> 7 <Payment> 8 <CardId> 9 <EncryptedData Type= h t t p : //www. w3. org /2001/04/ xmlenc#content 10 xmlns= h t t p : //www. w3. org /2001/04/ xmlenc# > 11 <EncryptionMethod 12 Algorithm= h t t p : //www. w3. org /2001/04/ xmlenc#t r i p l e d e s cbc /> 13 <CipherData> 14 <CipherValue>A23B45C564587</ CipherValue> 15 </ CipherData> 16 </ EncryptedData 17 </CardId> 18 <CardName>Mastercard</CardName> 19 <ValidDate> </ ValidDate> 20 </Payment> 21 </ purchaseorder> Abbildung 3.16: Verschlüsselte Kreditkartennummer. offentlichen Schl ussel im KeyValue-Element, eingebettet in ein Encrypted Key-Element, an den zweiten Teilnehmer. CarriedKeyName verweist auf den Namen des ubertragenen Schl ussels. Im n achsten Schritt erstellt der Empf anger einen Sessionkey und verschl usselt diesen mit dem soeben emp fangenen offentlichen Schl ussel des Senders im CipherValue-Element. Der Kommunikationsteilnehmer, welcher den Schlüsseltaustausch initiiert hat, entschlüsselt abschließend den Sessionkey. Nachdem der Schl ussel ausgetauscht wurde, werden die XML-Nutzdaten, wie im Beispiel illustriert, übertragen. Dazu wird das EncryptedData-Element (siehe Beispiele zuvor) verwendet, welches als Container f ur die verschl ussel ten Daten (CipherData) dient. Ob es sich beim verschlüsselten Teil um das gesamte Dokument, ein einzelnes Element (../xmlenc#element) oder nur den Elementinhalt (../xmlenc#content) handelt wird mit dem Type- Attribut des EncryptedData-Elements spezifiziert. EncryptionMethod teilt dem Emfp anger mit, welches Verfahren bei der Verschl usselung mit dem je weiligen Schl ussel angewandt wurde. Wird es nicht angegeben, m ussen sich die Kommunikationspartner bereits im Vorhinein über das eingesetzte Verfahren geeinigt haben. Das verpflichtende CipherData enthält den chiffrierten Text als Cipher- Value oder mit CipherReference eine Referenz auf die verschlüsselten Daten. Zusammenfassend sind folgende Schritte notwendig, um Informationen verschl usselt mit XML-Encryption zu ubertragen:

46 KAPITEL 3. SICHERHEIT VON WEB SERVICES 41 <EncryptedKey CarriedKeyName="Bart Simpsons" xmlns=' <ds:keyinfo xmlns:ds=' xmldsig#'> <ds:keyvalue> 1asd25fsdf2dfdsfsdfds2f1sd23 </ds:keyvalue> </ds:keyinfo> </EncryptedKey> <EncryptedKey CarriedKeyName="Lisa Simpsons" xmlns=' <EncryptionMethod Algorithm=" xmlenc#rsa-1_5"/> <CipherData> <CipherValue> xyza21212sdfdsfs7989fsdbc </CipherValue> </CipherData> </EncryptedKey> Mit dem Sessionkey verschlüsselte Daten Abbildung 3.17: Ablauf des Schlüsselaustausches. 1. (Optional) Austausch bzw. Einigung auf einen Sessionkey. 2. Festlegen, welche Teile des Dokuments verschlüsselt werden sollen. 3. Festlegung der EncryptionMethod und Verschlüsselung der sensiblen Daten. 4. Ersetzen der sensiblen Daten mit dem durch den Verschlüsselungsprozess erzeugten EncryptedData-Element. 5. Versenden der Daten im <wsse:security>-element des SOAP-Headers. 3.3 SAML SAML (Security Assertion Markup Language) erlaubt es, Informationen über Authentifizierungen und Authorisierungem standardisiert zwischen mehreren Teilnehmern auszutauschen. Der SAML-Standard [21] beschreibt die Syntax und Regeln zum Anfordern, Erstellen und Austauschen von SAML Assertions. SAML Assertions beinhalten Informationen über die Authentifizierung bzw. Authorisierung eines Objekts (principal). Der Aufbau der Assertions wird gegen das SAML Assertion XML Schema [22, S.11ff] validiert. Die Assertions treffen eine Aussage (statement) über ein subject. Beispielhaft beinhaltet eine Assertion, dass das Subjekt Monika Musterfrau heißt, die -Adresse hat und Mitglied in der Sales-Abteilung des Unternehmens ist. SAML definiert insgesamt die drei Assertion Statements Authentication, Attribute und Authorization Decision [21, S.14]. Das Beispiel in Abbildung 3.18 stellt einen Ausschnitt aus einer Assertion mit eingebettetem Authentication Statement dar.

47 KAPITEL 3. SICHERHEIT VON WEB SERVICES 42 1 <s a m l : A s s e r t i o n xmlns:saml= u r n : o a s i s : n a m e s : t c : S A M L : 2. 0 : a s s e r t i o n 2 V er s i on= 2. 0 I s s u e I n s t a n t= T12:00:00Z > 3 <s a m l : I s s u e r Format=urn:oasis:names :SAML:2. 0 :nameid f o r m a t : e n t i t y> 4 h t t p : // idp. example. org 5 </ s a m l : I s s u e r> 6 <s a m l : S u b j e c t> 7 <saml:nameid 8 Format= u r n : o a s i s : n a m e s : t c : S A M L : 1. 1 :nameid f o r m a t : e m a i l A d d r e s s > 9 monika. musterfrau@example. com 10 </saml:nameid> 11 </ s a m l : S u b j e c t> 12 <s a m l : C o n d i t i o n s 13 NotBefore= T12:00:00Z 14 NotOnOrAfter= T12:10:00Z > 15 </ s a m l : C o n d i t i o n> 16 <saml:authnstatement 17 AuthnInstant= T12:00:00Z S e s s i o n I n d e x= > 18 <saml:authncontext> 19 <saml:authncontextclassref> 20 u r n : o a s i s : n a m e s : t c : S A M L : 2. 0 : a c : c l a s s e s : P a s s w o r d P r o t e c t e d T r a n s p o r t 21 </ saml:authncontextclassref> 22 </ saml:authncontext> 23 </ saml:authnstatement> 24 </ s a m l : A s s e r t i o n> Abbildung 3.18: Beispiel einer SAML Assertion mit Subject, Condition und Authentication Statement.

48 KAPITEL 3. SICHERHEIT VON WEB SERVICES 43 Das Beispiel beginnt mit der Angabe, dass es sich um eine SAML Assertion handelt und gegen das angegebene XML Schema validiert werden kann. In Zeile 3-5 wird der Issuer (Aussteller) dieser Assertion beschrieben, in diesem Fall handelt es sich um idp.example.com. Nachfolgend (Zeile 6-11) wird das Subjekt der Assertion, unter Angabe des Formats (in diesem Fall ), näher beschrieben. Ferner folgt die Bedingung unter derer diese Assertion Gültigkeit hat: im Beispiel ist ein Zeitraum von zehn Minuten angegeben. Hier können weitere Bedingungen angegeben und neben den bereits vorhandenen auch eigene Bedingungen abgeleitet werden. Die Zeilen sagen schließlich, dass der Benutzer via PasswordProtectedTransport (eine Username/Passwort-Kombination) zur angegebenen Zeit erfolgreich authentifiziert wurde. Der Austausch der Assertions erfolgt eingebettet in SAML Protokollnachrichten. Der Aufbau der Request- und Responsenachrichten ist ebenfalls in [22, S.35ff] beschrieben. Der Bereich SAML Bindings [23] spezifiziert, wie das SAML Request Repsonse-Schema auf andere Protokolle abgebildet wird. In SAML 2.0 gibt es insgesamt sechs verschiedene Bindings, die wichtigsten sind: HTTP-Redirect, beschreibt wie der Transport mit Hilfe von HTTP- Responses mit Status 302 erfolgt. HTTP-POST definiert, wie die Übertragung mittels HTML-Form zu erfolgen hat. SAML SOAP spezifiziert wie die Authentifzierungsinformationen über das bei Web Services weit verbreitete SOAP funktioniert. SAML URI zeigt, wie die Informationen durch Links übertragen werden. SAML Profiles [24] zeigen schließlich ein Modell eines speziellen Anwendungsfall von SAML, beispielsweise SSO (Single Sign On) oder Konzepte zur Identity Federation (vgl. Seite 31). Diese Profile definieren Einschränkungen an den Inhalt der Assertions, Protokolle und Bindings um ein Konzept m oglichst interoperabel umzusetzen. Beispiele f ur SAML Profile sind: Web Browser SSO, Assertion Query/Request oder Name Identifier Mapping. Abbildung 3.19 fasst die beschriebene SAML Architektur mit den entsprechenden Komponenten grafisch zusammen. Um die Integrit at der ubertragenen SAML assertions sicherzustellen wird XML-Signature (siehe Seite 33) verwendet. 3.4 XACML XACML (extensible Access Control Markup Language) [26] spezifiziert ein XML-Schema zur Beschreibung von Authorisierungsrichtlinien für Ressour

49 KAPITEL 3. SICHERHEIT VON WEB SERVICES 44 Abbildung 3.19: Komponenten einer SAML-Architektur. [21, S.12] cen. Während das in Kapitel 3.3 vorgestellte SAML beschreibt, wie Assertions (siehe Seite 41) zu erstellen sind, beschreibt XACML die Richtlinien für die Definition und Interpretation der auf den SAML-Assertions basierenden Authorisierungsentscheidungen (engl. authorization decisions). SAML und XACML sind keine unterschiedlichen Ans atze f ur das gleiche Problem sondern ergänzen sich. Ein typisches Szenario zur Zugriffskontrolle und Authorisierung beinhaltet zumindest drei verschiedene Entitäten: ein Subjekt, eine Ressource und eine Aktion. Ein Subjekt führt einen (Authorisierungs-)Request durch, um eine bestimmte Aktion auf einer Ressource durchf uhren zu d urfen. Bei spielsweise stellt ein Entwickler (Subjekt) eine Authorisierungsanfrage an ein SVN-Repository um eine veränderte Quellcodedatei (Ressource) zu aktualisieren (Aktion). XACML definiert nach [27] u.a.: Eine Referenzarchitektur, die die verschiedenen an einem Autorisierungsprozess beteiligten Komponenten (Requestor, PEP, PDP, PAP, Context Handler) erfaßt. Eine Sprache zur Formulierung von Authorisierungsrichtlinien. 6 6 URL: control-xacml-2.0-core-specos.pdf. Abgerufen am

50 KAPITEL 3. SICHERHEIT VON WEB SERVICES 45 Ein Verarbeitungsmodell, d.h. wie man zur Entscheidung kommt, ob der Zugriff auf die Ressource erlaubt wird oder nicht. Abbildung 3.20: XACML-Referenzarchitektur. [28, S.9] Die XACML-Referenzarchitektur ist in Abbildung 3.20 dargestellt und umfasst den Policy Enforcement Point (PEP), den Policy Decision Point (PDP) sowie den Policy Administration Point (PAP) und den Context Handler. Eine Authorisierungsanfrage umfasst die Abarbeitung der folgenden Punkte. Eine Authorisierungsanfrage geht beim PEP ein. Als erstes erstellt der PEP mit XACML einen decision request und leitet diesen über den Context Handler an den PDP weiter. Dann wertet der PDP die Anfrage aufgrund der in der Anfrage enthaltenen Informationen aus. Falls n otig werden uber den Context Handler zusätzliche Informationen (Attributes) angefordert. Nach der Auswertung der Anfrage liefert der PDP einen von vier möglichen Werten an den PEP zurück: Permit: Das anfragende Subjekt hat die Erlaubnis die in der Anfrage definierte Aktion auf die Ressource durchzuführen. Deny: Das anfragende Subjekt hat nicht die Erlaubnis die in der Anfrage definierte Aktion auf die Ressource durchzuführen. Not Applicapable: Keine vom PDP bekannte Policy konnte angewendet werden. Indeterminate: Bei der Verarbeitung der Policy ist ein Fehler aufgetreten sodass der PDP keine Antwort liefern kann.