XML Web Services - WSE Security Enhancements

Transkript

1 XML Web Services - WSE Security Enhancements Ein Vortrag von Andreas Bissinger 2INF zu Veranstaltung Anwendung Rechnernetze im WS 2005/2006

2 Inhaltsverzeichnis 1 XML Web Services und ihre Unzulänglichkeiten Die GXA und Microsofts erste Implementation, WSE WSE Policy Messaging Routing Attachements mit SOAP Messages versenden Sicherheit mit WSE Wie WSE funktioniert Authentifizierung mit WSE Authentifizierung mittels Usernametoken Authentifizierung mittels X509 Zertifikat Beispiele zur digitalen Signatur und Verschlüsselung von XML Web Services mit WSE Ein Beispiel zur digitalen Signatur einer SOAP Messages (X509Signing) Ein Beispiel zur Verschlüsselung einer SOAP Messages (AsymmetricEncryption) Fazit... 19

3 1 XML Web Services und ihre Unzulänglichkeiten Durch den Einsatz von XML Web Services ergaben sich für viele verteilte Anwendungen erhebliche Vorteile. Zwar stellen XML Web Services in ihrem Grundsatz lediglich RPC Aufrufe dar, da aber der Informationsaustausch zwischen Client und Server nun in standardisierter Form über das SOAP Protokoll erfolgt, waren XML Web Services nun interoperabel einsetzbar und sprengten die Grenzen von Betriebssystemen, Anwendungen oder auch der Datendarstellung (Little Endian, Big Endian) auf. Als Übertragungsprotokoll der auf XML basierenden SOAP Messages diente im Allgemeinen http, obwohl SOAP darauf nicht festgelegt ist. Anfangs schien dies auch eine perfekte Lösung zu sein, da das http Protokoll mit TLS/SSL über Sicherungsmechanismen zum Schutz der Daten verfügt. Mit zunehmender Verbreitung der XML Web Services zeigten sich jedoch schon bald Schwächen in der Struktur. So machte sich das Fehlen von Mechanismen zu Transaktion, Reliable Messaging, Orchestration oder Security bald bemerkbar. Die Anbieter von XML Web Services versuchten in einem ersten Anlauf diese Schwächen zu beseitigen, indem sie das SOAP Protokoll mit Ihren eigenen Lösungen erweiterten und somit die von Ihnen benötigten Features implementierten. Neben dem enormen Zeit- und Kostenaufwand, den dies bedeutete, diente dies auch nicht dem Grundgedanken, XML Web Services interoperabel zu gestalten. Der erste Versuch, die erweiterten Protokolle zu standardisieren, scheiterte jedoch, da jeder Technologieanbieter seine erweiterten WS Protokolle zur Standardisierung an die von ihm priorisierte Standardisierungsstelle gab. (vgl. Abbildung 1) Corp A Corp B Corp C Corp D Abbildung 1*: Firmen übermitteln ihre Standards unkoordiniert an Standardisierungsgremien Anwendung Rechnernetze: XML Web Services WSE Security Enhancements Seite 1

4 Als Lösung dieses Dilemmas gründeten die führenden Anbieter von XML Web Service Technologien die WS-I (Web Service Interoperability Organization, Diese stellt kein neues Standardisierungsgremium dar, sondern ist ein Treffpunkt für Anbieter von Web Service Erweiterungen, dessen Aufgabe die Koordination der Standardisierungsvorschläge und die Weiterleitung an die Gremien ist. Sie stellt somit sicher, dass Erweiterungen von allen anerkannt werden und somit koordiniert zur Standardisierung gehen. (Abbildung 2) Corp A Corp B Corp C Corp D Working Group Abbildung 2*: WS-I koordiniert die Übermittlung von Standards an Standardisierungsgremien Da die Erweiterungen der XML Web Service Protokolle die bestehenden Protokolle eben nur erweitern, aber nicht verändern sollten, musste verschiedene Maßgaben eingehalten werden. So war es notwendig, das XML basierte Datenmodell der SOAP Messages nicht zu verändern. Weiterhin soll es möglich sein, aus den Erweiterungen nur diejenigen zu nutzen, die auch wirklich benötigt werden, das heisst, die Erweiterungen müssen modular nach einem Baukastenprinzip aufgebaut sein. Auch ist eine Dezentralisierung der Erweiterungen gefordert, das bedeutet, dass diese nicht von einem bestimmten Server abhängen, sondern von beliebigen Endpunkten der Kommunikation verstanden werden. Ebenfalls notwendig ist eine Neutralität in Bezug auf das Transportprotokoll. Die Erweiterungen müssen also unabhängig vom gewählten Transportprotokoll der SOAP Message funktionieren. Anwendung Rechnernetze: XML Web Services WSE Security Enhancements Seite 2

5 Realisiert wird dies nun dadurch, dass der Aufbau der SOAP Message nicht verändert wird. Eine solche Message besteht weiterhin aus einem optionalen Header und einem Body, die in dem SOAP Envelope eingebettet sind. Um die Erweiterungen nun bekannt zu machen wurde eine Menge von neuen SOAP Headern, allesamt optional, eingeführt, die die zusätzlichen Informationen beinhalten. Alle Erweiterungen haben zwar Einfluss auf die Kommunikation zwischen Client und Server, verändern aber die eigentlichen Nutzdaten, die vom XML Web Service abgearbeitet werden sollen nicht (solange man eine Verschlüsselung nicht als Veränderung sieht). 1.1 Die GXA und Microsofts erste Implementation, WSE 1.0 Microsoft entwickelte nun in Zusammenarbeit mit IBM, VeriSign u.a. die Global XML Architecture (GXA) als Umsetzung der Vorschläge des WS-I. Als erste Implementation kamen die XML Web Service Security Enhancements (WSE) 1.0 auf den Markt. Diese boten bereits ein erstes Set von Erweiterungen, speziell die Themen WS Security, WS Routing und WS Attachements betreffend. Mit den WSE 2.0 realisierte Microsoft einige Veränderungen und Erweiterungen der WSE WSE 2.0 Mit den WSE 2.0, die Microsoft 2003/2004 als Paket für das MS Visual Studio 2003 und das.net Framework herausbrachte, wurden die Möglichkeiten des WSE 1.0 erweitert und ergänzt. Zu den implementierten Haupteigenschaften der WSE 2.0 zählen die Sicherheit der XML Web Services unter dem Begriff WS Security, die Policy, SOAP Messaging, das Routing von SOAP Messages sowie das Versenden von Attachements mit den SOAP Messages. Die wohl derzeit bedeutendste Erweiterung liegt in der Absicherung von XML Web Services. Aus diesem Grund werde ich die anderen oben genannten Begriffe kurz erläutern und dann ausführlicher auf die Aspekte der Absicherung von XML Web Services eingehen. Anwendung Rechnernetze: XML Web Services WSE Security Enhancements Seite 3

6 2.1 Policy Unter Policy versteht man, dass Entwickler von XML Web Services nun die Voraussetzungen zum Senden und Empfangen von SOAP Messages in Konfigurationsdateien beschreiben können. Bisher musste der Empfänger einer Nachricht Code in seine Prozeduren aufnehmen, um zu erkennen ob die erforderlichen Voraussetzungen erfüllt werden, z.b. Ob die Nachricht digital signiert oder verschlüsselt ist. Der Sender einer Nachricht musste ebenso die Voraussetzungen des Empfängers kennen und die Nachricht dementsprechend aufbereiten. Dieses Festlegen von Voraussetzungen sollte aber eine administrative Aufgabe sein, nicht die des Programmierers. Dies wird durch das Einführen von Policy möglich, da diese Voraussetzungen nun als Konfigurationsdateien vorliegen. WSE 2.0 stellt für konfigurierte Policy Dateien Prozesse für ausgehende und eingehende SOAP Messages zur Verfügung, die bei ein- und ausgehenden Nachrichten die Einhaltung der jeweiligen Policy Konfiguration überprüfen und bei Fehlern oder Abweichungen eine Ausnahme werfen. 2.2 Messaging SOAP Messages werden zwar meist per HTTP Protokoll versendet, sind aber nicht daran gebunden. Werden die Nachrichten per HTTP über einen HTTP Server gesendet, erfolgt auf jedes HTTP request ein HTTP response. Dies ist aber nicht immer erwünscht. Gelegentlich will ein SOAP Message Sender nur Nachrichten versenden und benötigt oder erwartet keine Antwortnachricht. Messaging ermöglicht dies, indem Nachrichten nun asynchron direkt über TCP versendet werden. Dies ermöglicht den Versand ohne Einsatz eines Web Servers. Die anderen Features von WSE, z.b Signatur und Verschlüsselung von Nachrichten, bleiben dabei weiterhin nutzbar. 2.3 Routing Routing ermöglicht die Erstellung von verteilten Anwendungen, so dass die Netzwerktopologie für die Clients transparent ist. Dazu wird ein Computer als WSE Router konfiguriert, der von den anfragenden Clients die SOAP Messages erhält und diese an den Computer, der den XML Web Service hostet, weiterleitet. Anwendung Rechnernetze: XML Web Services WSE Security Enhancements Seite 4

7 (Abbildung 3) Dieses wird durch den Einsatz von Konfigurationsdateien erreicht. Besondere Bedeutung erlangt das Routing, wenn ein Web Server, der einen XML Web Service bereitstellt, gewartet werden muss oder ausfällt. Durch die Bereitstellung eines Ersatz Web Servers und die Änderung des Referral Cache des Routers kann ein XML Web Service auf den Ersatz Server geleitet werden, ohne dass der Nachrichtensender etwas davon mitbekommt. Abbildung 3: Ein als Server konfigurierter Router leitet die Anfragen an die Server weiter 2.4 Attachements mit SOAP Messages versenden Gelegentlich kann es erwünscht sein, dass mit einer SOAP Message Anhänge versendet werden sollen, die nicht XML konform sind, sondern Binärdarten enthalten, etwa große Texte oder Bilder. WE 2.0 ermöglicht dies mit Hilfe des Direct Internet Message Encapsulation (DIME) Protokolls. Dieses stellt einen Mechanismus bereit, der Anhänge außerhalb des SOAP Envelope plaziert und damit den zeit- und platz aufwendigen Vorgang der Serialisierung der Binärdaten nach XML umgeht. Dabei muss jedoch beachtet werden, dass die Anhänge nicht mit den noch zu erläuternden Sicherheitsmechanismen des WS Security versehen werden. Dies ist technisch bedingt, die Anhänge werden erst nach dem Umformen der SOAP Nachricht angehängt werden. Beim Versenden von Anhängen mit Hilfe der WS Attachements ist also selbst auf eine geeignete Methode zu Wahrung der Vertraulichkeit und Integrität der Daten sowie zur Sicherstellung der Authentizität des Senders zu achten. Anwendung Rechnernetze: XML Web Services WSE Security Enhancements Seite 5

8 3 Sicherheit mit WSE 2.0 Ursprünglich war es nur möglich, XML Web Services auf Basis von TLS / SSL zu sichern. Da diese Art der Verschlüsselung jedoch keine End zu End Verschlüsselung bietet, können SOAP Messages trotzdem abgefangen und im Klartext gelesen werden. (Abbildung 4) Unverschlüsselte Schwachstellen Sicherheitskontext Sicherheitskontext Sicherheitskontext Daten Daten Daten Abbildung 4: Datensicherheit bei SSL/TLS Verschlüsselung Die WSE 2.0 bieten für dieses Problem Vererbungsmechanismen an, die in den WS-Security Spezifikationen definiert sind. Dabei stehen Fragen der Authentifizierung, der Vertraulichkeit und der Integrität von Daten im Mittelpunkt. Gerade im Bereich des E-Commerce und der B2B, bzw B2C Anwendungen spielen diese Aspekte eine große Rolle. So werden immer häufiger vertrauliche Kreditkarteninformationen, aber auch personenbezogene oder anderweitig vertrauliche Daten an XML Web Services versendet. Somit bietet es sich an, innerhalb der Verwendung von XML Web Services die Daten so zu schützen, dass die Sicherheit von End- zu Endpunkt, also vom Versender zum Empfänger gewährleistet ist, unabhängig vom Übertragungsweg und Protokoll. (Abbildung 5) Sicherheitskontext Daten Daten Daten Abbildung 5: Sicherheitskontext mit WSE 2.0 Anwendung Rechnernetze: XML Web Services WSE Security Enhancements Seite 6

9 3.1 Wie WSE funktioniert Vereinfacht gesehen funktioniert die Einbindung von WSE 2.0 Methoden in ein Projekt in der Art, dass die SOAP Messages vor dem Versand an den Empfänger einen Outputfilter durchlaufen, der die jeweils notwendigen SOAP Header hinzufügt und die Nachricht entsprechend manipuliert. Diese Filter erledigen auch die gewünschte Verschlüsselung der Daten. Bei Empfänger werden die eingehenden SOAP Messages durch einen entsprechenden Inputfilter geleitet, der die manipulierte Nachricht wieder in ihren Ursprungs zustand zurück wandelt. (Abbildung 6) Abbildung 6*: Stellung der Input- und Outputfilter Die SoapWebRequest Klasse, die eine WSE 2.0 Spezifische Version der WebRequest Klasse des.net Frameworks ist, nutzt die SoapContext-Collection um die Output-Filter zu konfigurieren. Die Output-Filter fügen der ausgehenden SOAP-Nachricht dann die entsprechenden GXA-Spezifischen SOAP-Headers an. Die SoapWebResponse Klasse, auch eine WSE 2.0 spezifische Version der WebResponse Klasse, nutzt ebenfalls die SoapContext-Collection um die Input- Filter zu konfigurieren. Die Input-Filter lesen und entfernen die GXA-Spezifischen SOAP-Headers von der eingehenden SOAP-Nachricht. Abbildung 7*: Arbeitsweise der Outputfilter Anwendung Rechnernetze: XML Web Services WSE Security Enhancements Seite 7

10 3.2 Authentifizierung mit WSE 2.0 Ein Sicherheitsschwerpunkt der XML Web Services liegt in der Authentifizierung des SOAP Message Senders und Empfängers. Dafür bieten die WSE 2.0 verschiedene Möglichkeiten Authentifizierung mittels Usernametoken Die einfachste Möglichkeit stellt die Authentifizierung per Username und Passwort dar. Der Client erfragt Username und Passwort und sendet dies als Usernametoken an den Web Service Server. namespace BasicWSEClient { class BasicWSE2ConsoleApp { static void Main() { Console.WriteLine("Enter name: "); string name = Console.ReadLine(); Console.WriteLine("Enter password: "); string password = Console.ReadLine(); BasicWSEService.Service1Wse proxy = new BasicWSEService.Service1Wse(); // Only send over secure channel (note the 'S' in HTTPS) proxy.url = " proxy.requestsoapcontext.security.tokens.add( new UsernameToken(name, password, PasswordOption.SendPlainText)); Console.WriteLine(proxy.Hello(name)); Console.WriteLine("Hit Enter to end the program."); Console.ReadLine(); Abbildung 8: Clientcode zur Userauthentifizierung Dieser überprüft, ob der User einen gültigen Windows Account besitzt und Mitglied einer zulässigen Gruppe ist, und erfüllt dann die Anfrage. Anwendung Rechnernetze: XML Web Services WSE Security Enhancements Seite 8

11 [WebMethod] public string Hello(string name) { SoapContext ctxt = RequestSoapContext.Current; foreach (SecurityToken tok in ctxt.security.tokens) if (tok is UsernameToken) { UsernameToken user = (UsernameToken)tok; if (user.username == name) { if (user.principal.isinrole( System.Net.Dns.GetHostName() return "Hello, King " + name; return "Hello, " + name; return "Hello, Liar"; Abbildung 9: Code des Web Service Authentifizierung und Verschlüsselung mittels X509 Zertifikat Eine weitere unterstützte und wesentlich sicherere Methode ist die Authentifizierung mit einem X509 Zertifikat. Neben der Authentifizierung wird dieses Zertifikat auch zum digitalen Signieren und Verschlüsseln der SOAP Messages verwendet. Grundlage für die Verschlüsselung und Signatur von SOAP Messages bilden die von der W3C und der IETF verabschiedeten Standards XML DSig und XML Encryption XML DSig Der XML DSig Standard beschreibt eine Methode, um einen Key mit referenzierten Daten zu verknüpfen. Im konkreten Falle eine SOAP Message bedeutet das, dass über die kanonische Form der gesamten Nachricht, aber auch über die der einzelnen Elemente und deren Kindelemente, mit definierter Methode ein Hashwert gebildet werden kann, der dann dem Nachrichtenempfänger die Möglichkeit gibt, die Integrität der Daten zu überprüfen. Weiterhin ist es durch den Einsatz von Verschlüsselungsalgorithmen möglich, Die Nachrichten auch digital zu signieren und somit die Authentizität des Senders zu überprüfen. Am unten Anwendung Rechnernetze: XML Web Services WSE Security Enhancements Seite 9

12 folgenden Beispiel X509Signing aus dem WSE 2.0 Paketes für Microsoft Visual Studio 2003 wird dies noch ausführlicher erläutert XML Encryption Neben XML DSig gibt es vom W3C auch eine Empfehlung zur Verschlüsselung von XML Daten. Die zu verschlüsselnden Daten sind wieder das gesamte XML Dokument, also die SOAP Nachricht oder aber Elemente der Nachricht und deren Kindelemente. Als Verschlüsselungsalgorithmus können hierbei die verschiedensten Algorithmen zum Einsatz kommen, sowohl symmetrische, als auch asymmetrische Verschlüsselung. Da der Rechenaufwand bei großen Datenmengen und asymmetrischer Verschlüsselung aber sehr stark ansteigt, hat es sich bewährt, nicht die Daten asymmetrisch zu verschlüsseln, sondern einen symmetrischen Schlüssel asymmetrisch zu verschlüsseln und auszutauschen, der dann die Daten ver- und entschlüsselt. Auch dies werde ich an einem Beispiel (AsymEncryption) des WSE 2.0 Paketes demonstrieren. 4 Beispiele zur digitalen Signatur und Verschlüsselung von XML Web Services mit WSE 2.0 Die den WSE 2.0 beigelegten Codebeispiele sind alle so gestaltet, dass Client und Server auf dem selben Rechner liegen. Somit lassen sich die Datenpakete, die zwischen beiden hin und hergeschickt werden auch nicht mit einem Tool wie Ethereal auslesen. Über die Projekteigenschaften der einzelnen Projekte kann man jedoch in den WSE 2.0 Einstellungen auf dem Reiter Diagnostics das Message Tracing aktivieren, das die eingehenden und ausgehenden SOAP Messages logged und somit sichtbar macht. Voraussetzung für die Ausführung der Beispiele sind ein installiertes Microsoft Betriebssystem: Windows 2000 (Professional, Server, Advanced Server) mit SP 3, Windows XP (Home, Professional) mit SP 1 Windows Server 2003 Weiterhin werden der Microsoft Internet Information Service (IIS) in der Version 5.x oder höher benötigt, sowie das Microsoft.NET Framework SDK 1.1 bzw das Microsoft Visual Studio Anwendung Rechnernetze: XML Web Services WSE Security Enhancements Seite 10

13 Unbedingt benötigt werden noch die mit den Beispielen gelieferten Zertifikate, die in die richtigen Zertifikatsspeicher importiert werden müssen. Zum einen ist das das WSEQuickStartClient Zertifikat, zum anderen das WSE2QuickStartServer Zertifikat. 4.1 Ein Beispiel zur digitalen Signatur einer SOAP Messages (X509Signing) Diese Beispiel demonstriert, wie mit Hilfe der X509 Zertifikate eine SOAP Nachricht signiert wird und der Inhalt mittels Prüfsummenberechnung gegen Veränderung geschützt wird Ruft man das Beispiel auf, so erscheint eine Konsole, die anzeigt, dass sich der Client mit dem XML Web Service verbindet und nach einiger Zeit das Ergebnis der Anfrage. In der Konsole erscheint kein Hinweis darauf, dass die Nachricht in irgend einer Weise geschützt war oder ist. Betrachtet man aber die Output Datei des Message Tracers, also die SOAP Message, die der Client an den Server sendete erkennt man, dass diese von einer klassischen SOAP Message verschieden ist. (Abbildung 10) Anwendung Rechnernetze: XML Web Services WSE Security Enhancements Seite 11

14 <?xml version="1.0" encoding="utf-8"?> <soap:envelope xmlns:soap=" xmlns:xsi=" xmlns:xsd=" xmlns:wsa=" xmlns:wsse=" 1.0.xsd" xmlns:wsu=" 1.0.xsd"> <soap:header> <wsa:action wsu:id="id-0bea9418-b c-9e c530c"> <wsa:messageid wsu:id="id-3737ea0f-4b0a-4760-a172-56b11c7708d9">uuid:4467ea9e-2f50-4a4e-b6d5-4d1dabe64dd3 </wsa:messageid> <wsa:replyto wsu:id="id-5d9c05c feb-ab81-e a86"> <wsa:address> ess> </wsa:replyto> <wsa:to wsu:id="id-7b8d2c33-87ed-4beb-995f-aba1ad73d0a8"> <wsse:security soap:mustunderstand="1"> <wsu:timestamp wsu:id="timestamp-ce1e fc c6-bb e0"> <wsu:created> t19:21:28z</wsu:created> <wsu:expires> t19:26:28z</wsu:expires> </wsu:timestamp> Anwendung Rechnernetze: XML Web Services WSE Security Enhancements Seite 12

15 <wsse:binarysecuritytoken ValueType=" 1.0#X509v3" EncodingType=" 1.0#Base64Binary" xmlns:wsu=" 1.0.xsd" wsu:id="securitytoken-52b55db2-00c a0a4-4867b "> MIIBxDCCAW6gAwIBAgIQxUSXFzWJYYtOZnmmuOMKkjANBgkqhkiG9w0BAQQFADAWMRQwEg YDVQQDEwtSb290IEFnZW5jeTAeFw0wMzA3MDgxODQ3NTlaFw0zOTEyMzEyMzU5NTlaMB8xH TAbBgNVBAMTFFdTRTJRdWlja1N0YXJ0Q2xpZW50MIGfMA0GCSqGSIb3DQEBAQUAA4GNADC BiQKBgQC+L6aB9x928noY4+0QBsXnxkQE4quJl7c3PUPdVu7k9A02hRG481XIfWhrDY5i7OEB7K GW7qFJotLLeMec/UkKUwCgv3VvJrs2nE9xO3SSWIdNzADukYh+Cxt+FUU6tUkDeqg7dqwivOXhu OTRyOI3HqbWTbumaLdc8jufz2LhaQIDAQABo0swSTBHBgNVHQEEQDA+gBAS5AktBh0dTwCNY SHcFmRjoRgwFjEUMBIGA1UEAxMLUm9vdCBBZ2VuY3mCEAY3bACqAGSKEc+41KpcNfQwDQY JKoZIhvcNAQEEBQADQQAfIbnMPVYkNNfX1tG1F+qfLhHwJdfDUZuPyRPucWF5qkh6sSdWVBY5s T/txBnVJGziyO8DPYdu2fPMER8ajJfl </wsse:binarysecuritytoken> <Signature xmlns=" <SignedInfo> <ds:canonicalizationmethod Algorithm=" x mlns:ds=" /> <SignatureMethod Algorithm=" /> <Reference URI="#Id-0bea9418-b c-9e c530c"> <Transforms> <Transform Algorithm=" /> </Transforms> <DigestMethod Algorithm=" /> <DigestValue>45yhNyXmNnSAUI37Bun7wRSP8L0=</DigestValue> </Reference> <Reference URI="#Id-3737ea0f-4b0a-4760-a172-56b11c7708d9"> <Transforms> <Transform Algorithm=" /> </Transforms> <DigestMethod Algorithm=" /> <DigestValue>oPyqbR7cdQEDfts9xXW1fIotGG0=</DigestValue> </Reference> <Reference URI="#Id-5d9c05c feb-ab81-e a86"> <Transforms> <Transform Algorithm=" /> </Transforms> <DigestMethod Algorithm=" /> <DigestValue>i85zMsf/DzWv2vUbEt42CDAJ2Zs=</DigestValue> </Reference> <Reference URI="#Id-7b8d2c33-87ed-4beb-995f-aba1ad73d0a8"> <Transforms> <Transform Algorithm=" /> </Transforms> <DigestMethod Algorithm=" /> <DigestValue>RiTYEKVF8UomqunySjVBB8xipm8=</DigestValue> </Reference> <Reference URI="#Timestamp-ce1e fc c6-bb e0"> <Transforms> <Transform Algorithm=" /> </Transforms> <DigestMethod Algorithm=" /> <DigestValue>aFF/6entLtLnYsDFm9JPHqGUDdw=</DigestValue> </Reference> Anwendung Rechnernetze: XML Web Services WSE Security Enhancements Seite 13

16 <Reference URI="#Id b00-44d6-8fcb-41339a0938fa"> <Transforms> <Transform Algorithm=" /> </Transforms> <DigestMethod Algorithm=" /> <DigestValue>35BgWJWCNPaNIleHzP7bNFGb+1Y=</DigestValue> </Reference> </SignedInfo> <SignatureValue>kO3Mzduw/NmsLFDR+4Zzyu2p6fucpNrhOXPNbvKLKpE4+6iQ5Qr+H4aBhe q5bcng3b8yscemqw0c4mamjrniktm94f5xgghd0psbx+jdd2zz/1p4lube60rtufijrhzjmk95hi ZEP++kQ5p6XrJg7h87f866Km3WPwNTUCVoFKQ= </SignatureValue> <KeyInfo> <wsse:securitytokenreference> <wsse:reference URI="#SecurityToken-52b55db2-00c a0a4-4867b " ValueType=" /> </wsse:securitytokenreference> </KeyInfo> </Signature> </wsse:security> </soap:header> <soap:body wsu:id="id b00-44d6-8fcb-41339a0938fa"> <StockQuoteRequest xmlns=" <symbols> <Symbol>FABRIKAM</Symbol> <Symbol>CONTOSO</Symbol> </symbols> </StockQuoteRequest> </soap:body> </soap:envelope> Abbildung 10: WSE 2.0 modiizierte SOAP Message des Clients Im Header der SAOP Message sind die Namespaces und Elemente der WS Security Erweiterungen zu sehen. Diese beziehen sich auf das Addressing und die Security. Im weiteren Verlauf sind <Reference> Kindelemente des <Signature> Elementes zu erkennen. Diese haben jeweils ein eindeutiges URI Attribut in Form einer ID. Damit sind sie eineindeutig an die Elemente des Headers gekoppelt. Innerhalb eines jeden <Reference> Attributes gibt es ein Kindelement <DigestValue> in dem der Hashwert der kanonischen Form des zugehörigen Elementes kodiert in Base64 abgebildet ist. Der Algorithmus der Bildung des Hashwertes ist im <DigestMethod Algorithm> Tag festgelegt, die Methode der Umwandlung in die kanonische Form ist im <Transform Algorithm> Tag definiert, die Kindelemente des <Reference> Tags sind. Anwendung Rechnernetze: XML Web Services WSE Security Enhancements Seite 14

17 <Reference URI="#Id b00-44d6-8fcb-41339a0938fa"> <Transforms> <Transform Algorithm=" /> </Transforms> <DigestMethod Algorithm=" /> <DigestValue>35BgWJWCNPaNIleHzP7bNFGb+1Y=</DigestValue> </Reference> Lediglich das letzte <Reference> Tag ist nicht an ein Element des Headers gekoppelt, sondern hat die selbe ID wie der SOAP Body der Nachricht. Dessen <DigestValue> Wert ist der Base64 encodierte SHA1 Hashwert der kanonischen Form des SOAP Bodys. Bis zu diesem Punkt ist noch keine Sicherheit gegen Änderung der Daten erreicht, auch ist der Absender der Nachricht noch nicht validiert. Um dies zu erreichen, wird nochmals der Hashwert des gesamten Inhalts der kanonischen Form des <SignedInfo> Tags errechnet und mit dem privaten Schlüssel des SOAP Message Senders verschlüsselt. Dieses Ergebnis findet sich dann im <SignatureValue> Tag innerhalb des <Signature> Tag. <SignatureValue> ko3mzduw/nmslfdr+4zzyu2p6fucpnrhoxpnbvklkpe4+6iq5qr+h4abheq5 BCNG3b8ysCemqW0C4mAmJrniktm94F5xGgHd0psBx+jDd2ZZ/1P4lUBE60R TUFijRHzjMK95HIZEP++kQ5p6XrJg7h87f866Km3WPwNTUCVoFKQ= </SignatureValue> Nun kann der XML Web Service Anbieter seinerseits den Hashwert bestimmen, den übertragenen Hashwert aus dem <SignatureValue> Tag mithilfe des öffentlichen Schlüssels des Senders entschlüsseln und durch Vergleich die Authentizität des Senders und gleichzeitig die Integrität der Daten sicherstellen. Außerdem findet sich in der SOAP Message auch noch ein Element <BinarySecurityToken>. Anwendung Rechnernetze: XML Web Services WSE Security Enhancements Seite 15

18 Anwendung Rechnernetze: XML Web Services WSE Security Enhancements Seite 16

19 <wsse:binarysecuritytoken ValueType=" 1.0#X509v3" EncodingType=" -1.0#Base64Binary" xmlns:wsu=" 1.0.xsd" wsu:id="securitytoken-52b55db2-00c a0a4-4867b "> MIIBxDCCAW6gAwIBAgIQxUSXFzWJYYtOZnmmuOMKkjANBgkqhkiG9w0BAQQFA DAWMRQwEgYD VQQDEwtSb290IEFnZW5jeTAeFw0wMzA3MDgxODQ3NTlaFw0zOTEyMzEyMzU5NTlaMB8xHTAbB g NVBAMTFFdTRTJRdWlja1N0YXJ0Q2xpZW50MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBg Q C+L6aB9x928noY4+0QBsXnxkQE4quJl7c3PUPdVu7k9A02hRG481XIfWhrDY5i7OEB7KGW7qFJotL Le Mec/UkKUwCgv3VvJrs2nE9xO3SSWIdNzADukYh+Cxt+FUU6tUkDeqg7dqwivOXhuOTRyOI3HqbWT bu maldc8jufz2lhaqidaqabo0swstbhbgnvhqeeqda+gbas5aktbh0dtwcnyshcfmrjorgwfjeu MBI GA1UEAxMLUm9vdCBBZ2VuY3mCEAY3bACqAGSKEc+41KpcNfQwDQYJKoZIhvcNAQEEBQADQ Q AfIbnMPVYkNNfX1tG1F+qfLhHwJdfDUZuPyRPucWF5qkh6sSdWVBY5sT/txBnVJGziyO8DPYdu2fP M ER8ajJfl</wsse:BinarySecurityToken> Die ID dieses Token findet sich ebenfalls im <Signatur> Element im <KeyInfo> Tag wieder. Der Inhalt ist im Allgemeinen das verwendete Zertifikat in ASN.1 Darstellung als Base64 dekodierter String. Somit ist gesichert, dass der Server auch weiß, mit welchem Zertifikat er die Integrität der Daten und die Authentizität des Senders überprüfen muss. Dekodiert man den String von BASE64 in eine Binärdatei, kann man mithilfe des Programms GUIdumpASN von Peter Gutmann die Struktur des Zertifikates anzeigen. (Abbildung 11) Die oben gezeigte Methode sichert zwar die Authentizität und Integrität einer Nachricht, die Daten werden aber weiterhin im Body der SOAP Nachricht im Klartext übertragen. Um auch die Vertraulichkeit der Datenübertragung sicherzustellen, bedienen sich die WSE 2.0 der Verschlüsselung. Anwendung Rechnernetze: XML Web Services WSE Security Enhancements Seite 17

20 SEQUENCE { SEQUENCE { [0] { INTEGER 2 INTEGER C B 4E A6 B8 E3 0A 92 Error: Integer has a negative value. SEQUENCE { OBJECT IDENTIFIER md5withrsaencryption ( ) NULL SEQUENCE { SET { SEQUENCE { OBJECT IDENTIFIER commonname ( ) PrintableString 'Root Agency' SEQUENCE { UTCTime ' Z' UTCTime ' Z' SEQUENCE { SET { SEQUENCE { OBJECT IDENTIFIER commonname ( ) PrintableString 'WSE2QuickStartClient' SEQUENCE { SEQUENCE { OBJECT IDENTIFIER rsaencryption ( ) NULL BIT STRING 0 unused bits BE 2F A6 81 F7 1F 76 F2 7A 18 E3 ED C5 E7 C E2 AB B7 37 3D 43 DD 56 EE E4 F4 0D B8 F3 55 C8 7D 68 6B 0D 8E 62 EC E1 01 EC A1 96 EE A1 49 A2 D2 CB 78 C7 9C FD 49 0A A0 BF 75 6F 26 BB 36 9C 4F 71 3B D CC 00 EE E 0B 1B 7E A B A A8 3B 76 AC 22 BC E5 E1 B8 E4 D1 C8 E2 37 1E A6 D6 4D BB A6 68 B7 5C [ Another 12 bytes skipped ] [3] { SEQUENCE { SEQUENCE { OBJECT IDENTIFIER authoritykeyidentifier ( ) OCTET STRING 30 3E E4 09 2D 06 1D 1D 4F 00 8D DC A B 52 6F 6F E C 00 AA A 11 CF B8 D4 AA 5C 35 F4 SEQUENCE { OBJECT IDENTIFIER md5withrsaencryption ( ) NULL BIT STRING 0 unused bits 1F 21 B9 CC 3D D7 D7 D6 D1 B5 17 EA 9F 2E 11 F0 25 D7 C3 51 9B 8F C9 13 EE Anwendung 79 AA Rechnernetze: XML Web Services WSE Security Enhancements Seite A B B1 3F ED C4 19 D5 24 6C E2 C8 EF 03 3D 87 6E D9 F3 CC 11 1F 1A 8C 97 E5 Abbildung 11: ASN 1. Notation des Binary Security Token

21 4.2 Ein Beispiel zur Verschlüsselung einer SOAP Messages (AsymmetricEncryption) In diesem Beispiel der WSE 2.0 werden die Daten, die der Client an den Server überträgt verschlüsselt. Die Verschlüsselung erfolgt dabei bedingt durch die Funktionsweise der WSE 2.0 in 2 Schritten. Im ersten Schritt wird ein symmetrischer Session Key erzeugt, der zur Verschlüsselung und Entschlüsselung der Nachricht, bzw. Teilen der Nachricht dient. Der zweite Schritt verschlüsselt dann den symmetrischen Schlüssel mit dem öffentlichen Schlüssel des Empfängers und bettet diesen dann in den Header der SOAP Nachricht ein. Der Empfänger, und nur dieser ist nun in der Lage, den Session Key mit seinem privaten Schlüssel zu entschlüsseln und damit die Nachricht lesbar zu machen. (Abbildung 12) CryptoLib.dll Assembly DecryptionKeyProvider Class EncryptionKeyProvider Class RequestSoapContext ResponseSoapContext WSE_SymEncClient.exe Assembly F F WSE_SymEncWS XML Web service F F App.config: DecryptionKeyProvider Web.config: DecryptionKeyProvider F = Filter In diesem Beispiel zeige ich anhand der Ausgangsnachricht des Clients, wie die Verschlüsselung von SOAP Messages in WSE 2.0 arbeitet. Hier die XML Daten des Clients. (Abbildung 13) Anwendung Rechnernetze: XML Web Services WSE Security Enhancements Seite 19