Sicherheit in Webservices

Transkript

1 Hamid Saraha, Naima Fariss Fachgebiet Software Technik Fachbereich Informatik Technische Universität Darmstadt Zusammenfassung. Um Webservices in Geschäftsprozesse sicher nutzen zu können, war es notwendig einen Standard zu definieren, der die Sicherheitsanorderungen erfüllen sollte. Es gibt bereits Sicherheitsstandards, wie SSL oder IPSEC, aber sie gewährleisten nicht die erforderliche Ende-zu- Ende-Sicherheit für SOAP Nachrichten. WS-Security stellt Mechanismen zur Verfügung, um Nachrichten Integrität, Vertraulichkeit und Authentizität, aufbauend auf bestehende XML-Sicherheitsmechanismen zu gewährleisten und bettet diese in SOAP ein. Diese Arbeit soll zum einen Verständnis über WS- Security Mechanismen und die darauf basierenden Standards, WS-Trust, WS- Policy, WS-SecureConversation, WS-Federation, WS-Authorization und WS- Privacy ermitteln. Zum anderen werden einige Implementierungen von diesen Standards aus der Microsoft Welt mit.net und Java Welt vorgestellt. 1 Einführung Auch wenn Webservices so viele Vorteile mit sich bringen, wie Interoperabilität zwischen heterogenen und verteilten Anwendungen, werden sie vor allem in geschlossenen Anwendungsumgebungen angewendet. Für den Austausch der Nachrichten zwischen Anfrager (Requestor) und Anbieter (Provider) wird SOAP als Protokoll [5] verwendet. Das letzte bietet keine Sicherheitsmaßnahmen, sondern verlässt sich auf die Sicherheits-Features der darunter liegenden Transportprotokolle, wie SSL. SSL bietet Sicherheitsfunktionen für die Authentizität, Datenintegrität und Vertraulichkeit, ermöglicht aber nur eine Punkt zu Punkt Sicherheit. Da aber bei SOAP Nachrichten mehrere Vermittler an der Übertragung beteiligt werden können, könnte die Integrität, Vertraulichkeit und Authentizität der Nachricht verloren gehen. Daher ist die Anforderung nach einer Ende-zu-Ende-Sicherheit für Webservices besonders wichtig. WS-Security [10] erfindet keine neuen Technologien um dies zu erreichen, sondern verwendet dafür bestehende Standards und Spezifikationen. WS-Security beschreibt, wie die Sicherheitstoken für die Authentifizierung, XML Encryption und XML Signature zum Verschlüsseln und Signieren des Inhalts von XML-Nachrichten in einer SOAP Nachricht eingebunden werden. Basierend auf WS-Security wurden weitere Spezifikationen entwickelt. Diese umfassen WS-Trust, WS-SecureConversation, WS-Federation, WS-Authorization und WS-Privacy.

2 2 Motivation WS-Policy [28] ist ein Framework zur Beschreibung der Anforderungen, Präferenzen und Fähigkeiten eines Webservices. WS-Trust [24] ermöglicht das Ausstellen, Erneuern und Bestätigen von Sicherheitstoken zwischen Webservices und einem Sicherheitstokendienst. WS-Federation [31] definiert, wie Zusammenschlüsse mehrerer Vertrauenszonen in einem Verbund unter Verwendung von WS-Security, WS-Trust und WS-SecureConverstaion, gebildet wird. WS-Authorization definiert, wie Zugriffsrechte für Webservices spezifiziert und verwaltet werden. WS-Privacy ermöglicht das Formulieren von privaten bzw. unternehmensspezifischen Privacy- Einstellungen. In WS-SecureConversation [25] geht es speziell um den Aufbau und Austausch von Sicherheitskontexten, z.b. Token Austausch, Sitzungsaufbau. WS- Privacy und WS-Authorization Spezifikationen sind noch nicht veröffentlicht. Ziel dieser Arbeit ist es, in Kapitel 2 die Gründe, die zur Entwicklung von WS- Security Spezifikation geführt haben, zu erläutern, in Kapitel 3 Verständnis über WS- Security zu vermitteln. In Kapitel 4 werden die darauf basierende Sicherheitsspezifikationen genauer betrachtet, danach werden wir in Kapitel 5 einige Implementierungen von WS-Spezifikationen vorstellen. 2 Motivation Mit zunehmender Verbreitung werden Webservices immer häufiger das Ziel von Angriffen. Das liegt auch daran, dass Webservices das SOAP als Protokoll für den Nachrichtenaustausch verwenden. Dieses benutzt wiederum TCP, SMTP als Transport Protokoll, aber vor allem HTTP. Somit ist SOAP dieselben Risiken und Angriffe ausgesetzt wie HTTP. In diesem Abschnitt werden einige dieser Angriffe kurz erläutert [1,2]. DoS Angriff: dabei wird versucht die Verfügbarkeit eines Webservices, so einzuschränken, dass ein autorisierter Nutzer den Dienst nicht erreichen kann. Das könnte z.b. durch Überlasten der Ressourcen erfolgen. Dabei könnten unter anderem finanzielle Schaden entstehen. Mann in der Mitte Angriff: Durch Mann in der Mitte Angriff versucht ein Angreifer den Kommunikationskanal unter seiner Kontrolle zu bringen. Gelingt ihm das, kann er Zugang zu vertraulichen Informationen erlangen (Verletzung der Vertraulichkeit), sowie den kompletten Datenverkehr manipulieren (Verletzung der Integrität). Replay Attack Angriff: Bei einem Replay Attack Angriff könnte der Angreifer versuchen ein altes Authentifizierungsnachweis wieder zu verwenden um sich zu authentifizieren und damit einen unberechtigten Zugriff auf Informationen zu erlangen. Ein solcher Angriff kann durch Nonce oder Zeitstempel verhindert werden. XML Angriff: XML Angriff ist auch einer der möglichen Angriffe auf Webservices. Da Webservices zur Kommunikation XML Nachrichten verwenden, versucht der Angreifer ein Angriffsdokument mit sehr großer Tiefe und Größe zu senden. Verwendet der Service einen DOM-Parser (das komplette Objektmodell liegt im Speicher), um das Dokument zu parsen, werden die Ressourcen komplett 2

3 verbraucht, was in einem Todesfalls des Services führen kann (Denial of Services). Falsche Parametereingabe: dabei versucht der Angreifer, Schwachstellen in der Implementierung von Webservices zu nutzen. Eine Schwachstelle kann z.b. die Übernahme der Parameter ohne deren Gültigkeit zu überprüfen. So kann ein Angreifer bei der Übergabe eines Ungültigen Parameters, entweder den Service lahm legen (DoS), oder ein unerwartetes Verhalten verursachen. Ein weiteres Sicherheitsproblem, bekannt als Port 80 Problem, entsteht durch die Verwendung klassischer Firewalls. Firewalls bieten für Webservices nicht genügend Schutz, weil sie SOAP-Nachrichten nicht aufspüren. SOAP verwendet vor allem HTTP als Transport Protokoll, sodass die SOAP-Nachrichten klassische Firewalls einfach passieren können. Wird das SSL verwendet, um einen Webservice abzusichern, wird die gesamte Nachricht verschlüsselt und/oder signiert. Verschlüsseln oder Signieren eines oder mehrere Teile einer Nachricht ist nicht möglich. Außerdem bietet SSL nur eine Punktzu-Punkt-Sicherheit was für ein Webservice unzureichend ist. SSL SSL Abbildung 1: Punkt-zu-Punkt Sicherheit mit SSL Bei geschäftskritischen Anwendungen ist die Sicherheit in Webservices besonders wichtig. Daher ist es notwendig die Sicherheitsanforderungen beim Entwurf von Webservices zu bedenken. Integrität, Vertraulichkeit und Authentizität gehören zu diesen Sicherheitsanforderungen. Bei der Integrität soll der Webservice in der Lage sein zu erkennen, ob die Nachricht während des Transports manipuliert wurde und versuchen das zu verhindern. Bei der Vertraulichkeit soll der Webservice gewährleisten, dass die Nachricht nur von befügten Partnern gelesen wird. Um dies zu erreichen wird die Nachricht mit einem Verschlüsselungsschlüssel verschlüsselt übertragen. Nur mit einem entsprechenden Entschlüsselungsschlüssel kann die Nachricht wieder entschlüsselt werden. Bei der Authentizität geht s darum die Identität gegenüber dem Kommunikationspartner nachzuweisen. Aus diesen Gründen wurden verschiedene Sicherheitsmechanismen für Webservices entwickelt. Einer von diesen Sicherheitsmodellen ist das WS-Secruity Standard, der ursprünglich von IBM, Microsoft und VeriSign entwickelt wurde. 3 WS-Security WS-Security [10, 18, 20, 21] integriert und vereinheitlicht diverse Sicherheitsmodelle, -mechanismen und -technologien, die die Zusammenarbeit einer großen Zahl von 3

4 3 WS-Security Systemen ermöglichen sollte. Im März 2004 wurde WS-Security Version 1.0 von OASIS zum ersten Mal standardisiert. Mittlerweile wurde die Version 1.1 im Februar 2006 verabschiedet. WS-Security bietet Mechanismen zum Versenden der Sicherheitstokens als Teil der SOAP-Nachricht und zum Gewährleisten der Nachrichten- Integrität Authentizität und Vertraulichkeit. WS-Security definiert, wie bestehende XML- Sicherheitsmechanismen, wie XML-Canonicalization [8], XML-Signature [7] und XML-Encryption [6] in SOAP-Nachrichten integriert und wie Sicherheitstokens, wie UserName-, X.509-Tokens eingebunden werden. In Version 1.1 sind zusätzliche Profile für SAML-, Kerberos-, Rights Expression Language (REL) Tokens, sowie Profile für SOAP Anhängen hinzugekommen. Sicherheitstokens Nicht signierte Sicherheitstokens Username Signierte Sicherheitstokens X.509 Zertifikat Kerberos Tickets Abbildung 2: Signierte und nicht signierte Security Tokens Bevor wir WS-Security genauer betrachten, werden wir zunächst kurz auf die XML- Sicherheitsmechanismen eingehen. Danach werden wir WS-Security Mechanismen genauer erläutern. 3.1 XML Encryption XML-Encryption [6] ist eine Spezifikation von W3C, sie definiert eine Reihe von Möglichkeiten, wie XML-Dokumente ver- und entschlüsselt werden. Dabei kann das gesamte XML-Dokument, einen einzelnen Element und seine Unterelemente, das Inhalt eines XML Elementes oder das XML-Dokument für mehrere Empfänger verschlüsselt werden. Eine weitere Besonderheit bei XML-Encryption ist die Canonicalization [8], das ist eine Normalisierung des XML-Dokumentes, die gewährleistet, dass Namespace-Bindungen auch beim entschlüsseln innerhalb einer anderen Umgebung korrekt umgesetzt werden. Listing 1 zeigt ein Beispiel für die Verschlüsselung. 4

5 <EncryptedData Type= /04/xmlenc#Element'/ > <EncryptionMethod Algorithm= AES-128-CBC /> <KeyInfo> <KeyName>Secret Key 4711</KeyName> <EncryptedKey> <EncryptionMethod Algorithm= RSA /> <KeyInfo> <X509Data> <X509SubjectName>DN=John Doe</X509SubjectName> </X509Data> </KeyInfo> <CipherData> <CipherValue>349854eg943y</CipherValue> </CipherData> </EncryptedKey> </KeyInfo> <CipherData> <CipherValue>a3e7896f9</CipherValue> </CipherData> </EncryptedData> Listing 1: XML Encryption EncryptedData: Element für die XML Verschlüsselung. Das Attribut "Type" ist optional und weist darauf, ob ein komplettes XML Element oder nur der Inhalt des Elementes verschlüsselt werden soll. EncryptedMethod/Algorithm: Das Element ist optional und beschreibt den verwendeten Algorithmus, der zur Verschlüsselung verwendet wird. Wenn dieses Element nicht verwendet wird, dann muss der Verschlüsselungsalgorithmus dem Empfänger bekannt sein. KeyInfo: Enthält Informationen über den zur Verschlüsselung verwendete Schlüssel. Das Element ist auch optional. EncryptedKey: Enthält den asymmetrisch verschlüsselten symmetrischen Schlüsseln, was bei hybride Verschlüsselungsmechanismen gebraucht wird. CipherData: Enthält entweder die Darstellung der verschlüsselten Daten (CipherValue) oder eine Referenz (CipherReference) auf die Ressource, wo sie gespeichert sind. Dieses Element ist nicht optional. CipherValue: Beinhaltet die verschlüsselten Daten. CipherReference: ist eine Referenz zu den verschlüsselten Daten. 3.2 XML Signature Analog zu XML-Encryption definiert XML-Signature [7] wie XML-Dokumente digital signiert und wie digitale Signaturen in XML eingebettet werden. XML- Signature bietet Integrität, Authentizität und/oder Signierer Authentizität für Daten, die sich entweder innerhalb oder außerhalb des XML-Dokumentes befinden. Es ist möglich, komplettes XML Dokument oder nur Fragmente davon zu signieren. Auch 5

6 3 WS-Security bei XML-Signature spielt die Canonicalization eine bedeutende Rolle, denn dadurch werden verschieden formatierte XML-Dokumente, die inhaltlich identisch sind, die gleiche Signatur erhalten. Es gibt drei Signature Typen: Enveloped: Die Signatur ist als Element im signierten Dokument enthalten. Enveloping Signature umschließt das ganze XML-Dokument Detached Signierter Element liegt getrennt von der Signatur. Daten werden über URI oder Transformation referenziert. Signiertes XML Dokument XML Signature XML Dokument XML Signature Signiertes XML Dokument XML Dokument XML Signature Signierte Daten XML oder non XML Abbildung 3: XML Signature Typen 3.3 WS-Security-SOAP-Header WS-Security definiert ein SOAP-Header Element, in dem sicherheitsbezogene Daten enthalten sind. Ein <wsse:security> Header-Block kann mehrere WS-Security Header-Blocks enthalten, jeder Header-Block ist durch einen eindeutigen Akteur definiert. <wsse:security> darf nicht mehrere Header-Blocks enthalten, die für denselben Empfänger ausgerichtet sind. Header-Blocks dürfen das Attribut S11:actor oder S12:role auslassen. Durch S11:mustUnderstand wird angegeben, ob die Header- Angaben verpflichtend oder optional für den Empfänger sind, je nachdem ob der Wert 1 oder 0 ist. 6

7 <S11:Envelope> <S11:Header> <wsse:security > <wsse:binarysecuritytoken > </wsse:binarysecuritytoken> <xenc:encryptedkey> </xenc:encryptedkey> <ds:signature> </ds:signature> </wsse:security>... </S11:Header> <S11:Body> <xenc:encrypteddata Id="ID"> </S11:Body> </S11:Envelope> SOAP Envelope Security Header Security Token Signature Encrypted Key SOAP Body Encrypted Data Abbildung 4: Einbettung von Sicherheitsinformation in einer SOAP-Nachricht 3.4 Security Tokens Die WS-Security Spezifikation definiert verschiedene Typen von Sicherheitstoken und, wie sie in einer SOAP Nachricht eingebunden werden können Username/Password Token Username/Passwort Token [11] ist am häufigsten benutzte Methode, um Anmeldeinformation zu übergeben. Das Übergeben eines UsernameToken in einer SOAP-Nachricht sieht folgendermaßen aus: <wsse:usernametoken wsu:id="example-1"> <wsse:username>... </wsse:username> <wsse:password Type="...">... </wsse:password> <wsse:nonce EncodingType="...">... </wsse:nonce> <wsu:created>... </wsu:created> </wsse:usernametoken> Listing 2 : Username Token Wenn <wsse:password Type = PasswordText> verwendet wird, wird das Passwort im Klartext übertragen. Um das Passwort sicherer übertragen zu können, könnte das Attribut PasswordDigest benutzt werden. Nonce und Created sind optional. Listing 3 zeigt die Verwendung von PasswordDigest. Mit Hilfe von SHA-1 könnte der Hashwert unter Verwendung von Nonce, Erstellungsdatum (Created) und das Passwort berechnet werden: 7

8 3 WS-Security <wsse:usernametoken> <wsse:username> </wsse:username> <wsse:password Type="wsse:PasswordDigest"> KB6QkldOpkPyTGGgdT30W4Keg=</wsse:Password> <wsse:nonce>9uq4abku/m6/trbrne+l7vg==</wsse:nonce> <wsu:created xmlns:wsu= " T00:44:02Z </wsu:created> </wsse:usernametoken> Listing 3: Username Token mit PasswordDigest Binary Security Tokens Binary Security Tokens können X.509 Zertifikat, Kerberos Tickets oder auch andere non-xml basierte Sicherheitstokens. <wsse:binarysecuritytoken> Element definiert zwei Attribute. ValueType definiert den Typ des Tokens, Kerberos Ticket oder X.509 Zertifikat. EncodingType gibt an, welches Kodierungsformat benutzt wird (z.b. Base64 encoded). Die Syntax sieht folgendermaßen aus: <wsse:binarysecuritytoken wsu:id=... EncodingType=... ValueType=.../> Listing 4 : BinarySecurityToken Durch das Attribut wsu:id und das Element <wsse:securitytokenreference> werden die Sicherheitstokens identifiziert und referenziert. X.509 Token Ein X.509 Zertifikat [12] wird benutzt, um die Authentifizierung, Verschlüsselung und Signierung von Nachrichten zu gewährleisten. Das Zertifikat [2] stellt eine Bindung zwischen dem öffentlichen Schlüssel und seinen Besitzer dar, egal ob der Schlüssel zum Verschlüsseln, zum Signieren oder zum Authentifizieren verwendet wird. Dieser Token wird in SOAP Nachrichten eingebunden, indem der ValueType auf wsse:x509v3 gesetzt wird. Eine solche Einbindung könnte folgendermaßen aussehen: <wsse:binarysecuritytoken ValueType="wsse:X509v3" EncodingType="wsse:Base64Binary" Id="SecurityToken-f49bd662-59a0-401a-ab23-1aa f">... </wsse:binarysecuritytoken> Listing 5: BinarySecurityTokem mit eine X-509 Zertifikate 8

9 Kerberos Ticket Kerberos [2] ist ein Authentifizierungsdienst, der das Single-Sign-On Konzept realisiert. Er verwendet so genannte Tickets zur Authentifizierung. Der Kerberos Ticket [14] wird in SOAP-Nachricht eingebunden, indem der ValueType auf wsse:kerberosv5tgt gesetzt wird. Listing 6 veranschaulicht wie ein Kerberos Ticket in SOAP Nachricht eingebunden wird. <S11:Envelope xmlns:s11="..." xmlns:wsu="..."> <S11:Header> <wsse:security xmlns:wsse="..."> <wsse:binarysecuritytoken EncodingType=" #Base64Binary" ValueType=" #Kerberosv5_AP_REQ" wsu:id="mytoken"> ccgawibbaedageoogcd... </wsse:binarysecuritytoken>... </wsse:security> </S11:Header> <S11:Body>... </S11:Body> </S11:Envelope> Listing 6: BinarySecurityToken mit Kerberos Ticket Andere Tokens: SAML Token: Security Assertion Markup Language (SAML) [9] ist ein XML basiertes Framework, das den sicheren Austausch von Authentifizierungs- und Autorisierungsinformationen, anhand von so genannten Assertions, dient. So ist es beispielsweise möglich zu bestätigen, dass ein gültiges Passwort angegeben wurde. Diese Spezifikation definiert, wie SAML V1.1 und V2.0 Zusicherungen (assertions) in SOAP-Nachricht als Sicherheitstoken eingebunden werden können. dafür müssen SAML Assertions Elemente oder Ihre Referenzen in <wsse:security> Element eingefügt und mit XML Signature signiert werden [13]. Listing 7 zeigt, wie SAML Token in wsse:security integriert werden kann: <S12:Header> <wsse:security xmlns:wsse="..."> <saml:assertion xmlns:saml="..." AssertionID="_a75adf55-01d7-40cc-929f-dbd8372ebdfc" IssueInstant=" T00:46:02Z" Issuer= MajorVersion="1" MinorVersion="1"> <saml:authenticationstatement> <saml:subject> <saml:nameidentifier 9

10 3 WS-Security.. Listing 7 : SAML Token NameQualifier= REL Token Profile: Die Right Expression Language (REL) ist auch eine XML basierte Sprache zur Beschreibung der Rechte und Bedingungen für das Nutzen von Ressourcen. WS- Security bindet diesen Token in SOAP Nachricht ein, indem das <r:license> Element innerhalb von <wsse:security> platziert wird [15], wie in Listing 8 gezeigt wird. <S:Envelope xmlns:s="..."> <S:Header> <wsse:security xmlns:wsse="..."> <r:license xmlns:r="...">... </r:license>... </wsse:security> </S:Header> <S:Body>... </S:Body> </S:Envelope> Listing 8 : REL Token Profile SOAP Messages with Attachments Token (SwA): Die WS-Security Spezifikation beschreibt wie ein WebService Benutzer sein SOAP Nachricht mit Anhängen durch SOAP Message Security für Anhänge- Integrität, Vertraulichkeit und Ursprungsauthentizität sichern kann und wie ein Empfänger solche Nachricht verarbeiten kann [16]. 3.5 Signatur Durch Signaturen [1,2] wird nicht nur die Integrität der Nachricht sichergestellt sondern auch die Authentizität des Signierers. Die Spezifikation erlaubt das Anhängen mehrerer Signaturen auch unterschiedlicher Signaturformaten. Das ist besonders für verteilte Umgebungen wichtig, bei denen Nachrichten über mehrere Ebenen bearbeitet werden müssen. WS-Security baut auf das XML-Signature Standard und hat daher dieselben Algorithmen-Anforderungen wie in XML-Signature Spezifikation beschrieben ist. Um in SOAP Nachricht eine Signatur hinzufügen, muss das Element <ds:signature> zum vorhandenen Inhalt von <wsse:security> vorangestellt werden. Als zweite Bedingung müssen SOAP Applikationen in der Lage sein, die benötigten Elemente, die in der XML Signature Spezifikation definiert sind, zu bearbeiten. Listing 9 zeigt die Benutzung von Integritäts- und Sicherheitstockens, dabei wird nur der Body signiert. 10

11 <?xml version="1.0" encoding="utf-8"?> <S11:Envelope xmlns:s11="..." xmlns:wsse="..." xmlns:wsu="..." xmlns:ds="..."> <S11:Header> <wsse:security> <wsse:binarysecuritytoken ValueType="...#X509v3" EncodingType="...#Base64Binary" wsu:id="x509token"> MIIEZzCCA9CgAwIBAgIQEmtJZc0rqrKh5i... </wsse:binarysecuritytoken> <ds:signature> <ds:signedinfo> <ds:canonicalizationmethod Algorithm= " /10/xml-exc-c14n#"/> <ds:signaturemethod Algorithm= " /2000/09/xmldsig#rsa-sha1"/> <ds:reference URI="#myBody"> <ds:transforms> <ds:transform Algorithm=" /2001/10/xml-exc-c14n#"/> </ds:transforms> <ds:digestmethod Algorithm=" #sha1"/> <ds:digestvalue>eulddytso1...</ds:digestvalue> </ds:reference> </ds:signedinfo> <ds:signaturevalue> BL8jdfToEb1l/vXcMZNNjPOV... </ds:signaturevalue> <ds:keyinfo> <wsse:securitytokenreference> <wsse:reference URI="#X509Token"/> </wsse:securitytokenreference> </ds:keyinfo> </ds:signature> </wsse:security> </S11:Header> <S11:Body wsu:id="mybody"> <tru:stocksymbol xmlns:tru=" QQQ </tru:stocksymbol> </S11:Body> </S11:Envelope> Listing 9 : Digital Signature Beispiel 3.6 Verschlüsselung Um die Vertraulichkeit der SOAP Nachricht zu bewahren, müssen die Daten verschlüsselt übertragen werden. Die WS-Security Spezifikation erlaubt die Verschlüsselung jeder Kombination aus Body-, Header-Blocks und Anhängen entweder durch einen gemeinsamen symmetrischen Schlüssel vom Sender und Empfänger oder durch einen symmetrischen Schlüssel, der in der Nachricht verschlüsselt übertragen wird. WS-Security baut hierfür auf das existierende XML- 11

12 3 WS-Security Encryption Standard. Dabei dürfen die Elemente Header, Envelope und Body nicht verschlüsselt werden. Die verschlüsselten Elemente müssen innerhalb von EncryptedData Element enthalten sein und durch das Element ReferenceList referenziert werden. Listing 10 zeigt eine WS-Security basierte SOAP-Nachricht mit den eingebetteten XML Encryption Informationen: <?xml version="1.0" encoding="utf-8"?> <soap:envelope xmlns:soap=" xmlns:xenc=" <soap:header xmlns:wsse=" xmlns:wsu=" <wsu:timestamp> <wsu:created wsu:id="id-3beeb885-16a4-4b65-b14c-0cfe6ad26800"> T00:26:15Z </wsu:created> <wsu:expires wsu:id="id-10c aa54"> t00:31:15z </wsu:expires> </wsu:timestamp> <wsse:security soap:mustunderstand="1" > <xenc:referencelist> <xenc:datareference URI="#EncryptedContent-41d3-aac4-76f2e51"/> </xenc:referencelist> <xenc:referencelist> <xenc:datareference URI="#EncryptedContent-a9e b9d43b6" /> </xenc:referencelist> </wsse:security> </soap:header> <soap:body> <xenc:encrypteddata Id="EncryptedContent-41d3-aac4-376f2e51" Type=" <xenc:encryptionmethod Algorithm= " /04/xmlenc#tripledes-cbc"/> <KeyInfo xmlns=" <KeyName>Symmetrischer Schlüssel</KeyName> </KeyInfo> <xenc:cipherdata> <xenc:ciphervalue>uit... VZQqnPpZYMg==</xenc:CipherValue> </xenc:cipherdata> </xenc:encrypteddata> </soap:body> </soap:envelope> Listing 10 : Beispiel einer Nachricht Verschlüsselung WS-Security ermöglicht das Authentifizieren, das Signieren, und das Verschlüsseln von SOAP Nachrichten. Dabei werden die dafür notwendigen Informationen mit der Nachricht versendet. Dadurch ist die Nachricht unabhängig von dem Transportweg, und die Ende-zu-Ende-Sicherheit sollte damit erreicht werden. 12

13 4 Weitere Sicherheitsmechanismen Zusätzlich zu WS-Security wurden mehrere Sicherheitsspezifikationen veröffentlicht, die auf WS-Security aufbauen bzw. es ergänzen. Abbildung 4 zeigt die Hierarchie dieser Spezifikationen. WS- Secure Conversation WS-Federation WS-Autorization WS-Policy WS-Trust WS-Privacy WS-Security SOAP Abbildung 5: Übersicht der Sicherheitsspezifikationen für Webservices 4.1 WS-Trust WS-Security definiert ein Framework zum Sichern von SOAP-Nachrichten, das auf bestehende XML-Sicherheitsmechanismen und Sichereitstokens basiert. Die Sicherheitstokens definieren ein Identitätskonzept und enthalten meist Informationen über den verwendeten Schlüssel. Die WS-Security definiert, wie diese Tokens in einer SOAP-Nachricht eingebunden werden und wie darauf verwiesen wird, legt aber nicht fest, wie man diese Tokens anfordern kann. Beispiele von Sicherheitstokens sind z.b. X509 Zertifikate, Kerberos Tickets und Username/Password Tokens. WS-Trust [24,26] baut auf und erweitert WS-Security um einen Dienst zur Anforderung, Ausgabe, Austausch und Validierung von Sicherheitstokens. Durch WS-Trust können vertrauenswürdige Verbindungen etabliert werden Anfordern von Sicherheitstoken Das Anfordern von Sicherheitstokens kann entweder durch ein Programm oder ein Sicherheitstokendienst erfolgen und basiert auf einen Sicherheitstoken, wie z.b. eine X-509 Zertifikat, die dem Anfrager und dem Sicherheitstokendienst (STS) bekannt ist. Der Sicherheitstokendienst kann ein Token entweder ausstellen, erneuern oder überprüfen. Zum Anfordern von Tokens sendet der Anfrager dem 13

14 4 Weitere Sicherheitsmechanismen Sicherheitstokendienst eine so genannte RST-Nachricht (Request Security Token). Falls die Policies es erlauben und die Anforderungen des Empfängers erfüllt sind, erhält der Anfrager dann ein Token als Antwort. Dafür sind zwei Elemente <RequestSecurityToken> und <RequestSecurityTokenResponse> definiert. Zum Anfordern eines Sicherheitstokens wird das <RequestSecurityToken> Element verwendet. Dieses Element soll vom Anfrager unter Verwendung von Tokens, die für diese Anfrage relevant sind, signiert werden. Listing 11 zeigt die Syntax von <RequestSecurityToken>: <RequestSecurityToken> <TokenType>...</TokenType> <RequestType>...</RequestType> <Base>...</Base> <Supporting>...</Supporting> </RequestSecurityToken> Listing 11 : Anfordern eines Sicherheitstoken RequestSecurityToken: Definiert eine Anfrage zum Ausstellen eines Tokens RequestSecurityToken/TokenType: Dieses optionale Element beschreibt den Typ des angeforderten Tokens, das vom <RequestSecurityTokenResponse> Element zurückgegeben soll. RequestSecurityToken/RequestType: Dieses legt der Typ der Operation fest, die vom Sicherheitstokendienst durchgeführt werden soll. Die folgenden Formate sind vordefiniert. Name Beschreibung wsse:reqissue Ausstellen eines Sicherheitstoken wsse:reqvalidate wsse:reqexchange Überprüfen eines Sicherheitstoken Erneuern eines Sicherheitstoken Tabelle1: RequestType Formate RequestSecurityToken/Base: Dieses optionale Element stellt ein Basis- Sicherheitstoken für die Anfrage zur Verfügung. RequestSecurityToken/Supporting: Dieses optionale Element referenziert Tokens. Im Listing 12 soll ein X-509 Sicherheitstoken ausgestellt werden. Dieses Token basiert auf das Sicherheitstoken mit der ID MyToken in dem Security Header. Das Token spezifiziert ein Username, Nonce und ein Zeitstempel. 14

15 <S:Envelope xmlns:s="..." xmlns=".../secext" xmlns:wsu=".../utility> <S:Header>... <Security> <UsernameToken wsu:id="mytoken"> <Username>NNK</Username> <Nonce>FKJh...</Nonce> <wsu:created> t09:00:00z </wsu:created> </UsernameToken> <ds:signature xmlns:ds="...">... </ds:signature> </Security> </S:Header> <S:Body wsu:id="req"> <RequestSecurityToken> <TokenType>wsse:X509v3</TokenType> <RequestType>wsse:ReqIssue</RequestType> <Base> <Reference URI="#myToken"/> </Base> </RequestSecurityToken> </S:Body> </S:Envelope> Listing 12 : Ausstellen einer X-509 Sicherheitstoken Rückgabe eines Sicherheitstoken Für die Rückgabe eines Sicherheitstokens wird das Element RequestSecurityTokenResponse verwendet. Dieses Element hat die folgende Syntax: <RequestSecurityTokenResponse> <TokenType>...</TokenType> <KeyType>...</KeyTyp> <KeySize>...</KeySize> <wsp:appliesto>...</wsp:appliesto> <RequestedSecurityToken>..</RequestedSecurityToken> <RequestedProofToken>...</RequestedProofToken> </RequestSecurityTokenResponse> Listing 13: Rückgabe eines Sicherheitstoken RequestSecurityTokenResponse: Dieses Element spezifiziert die Rückgabe eines Requests. RequestSecurityTokenResponse/TokenType: Das optionale Element spezifiziert den Typ des Tokens, das zurückgegeben wird. RequestSecurityTokenResponse/KeyType: Dieses optionale Element spezifiziert den Typ, des in diesem Token verwendeten Schlüssel. 15

16 4 Weitere Sicherheitsmechanismen RequestSecurityTokenResponse/KeySize: Dieses optionale Element definiert die Größe des verwendeten Schlüssels RequestSecurityTokenResponse/wsp:AppliesTo: Dieses Element definiert den Gültigkeitsbereich für das Sicherheitstoken. RequestSecurityTokenResponse/RequestedSecurityToken: Dieses optionale Element liefert das abgefragte Sicherheitstoken zurück. 4.2 WS-Policy WS-Policy [28, 34, 21] wurde von IBM, Microsoft, BEA und SAP veröffentlicht und wurde entworfen, um mit dem allgemeinen Webservices Framework, inklusive WSDL [4] und UDDI [3] zu arbeiten. WS-Policy ist ein Framework zur Beschreibung der Anforderungen, Präferenzen und Fähigkeiten eines Webservices. Solche Anforderungen und Bedingungen werden als so genannte Policies-Assertions ausgedrückt. Unter Assertion versteht man eine individuelle Anforderung, Fähigkeit oder Eigenschaft und müssen in spezifischen Anwendungsbereichen definiert werden. So kann eine Assertion z.b. bestimmen, dass Nachrichten, die mit einem Webservice ausgetauscht werden, nur mit einem bestimmten Verfahren zu verschlüsseln sind. Policies-Ausdrücke werden mit Hilfe von Operatoren kombiniert. Der <All> Operator z.b. spezifiziert, dass alle eingeschlossenen Assertions und Policies- Ausdrücke erfüllt sein müssen. Dagegen spezifizieren die beiden Operatoren <ExaclyOne> und <OneorMore>, dass genau eines bzw. mehrere Elemente eingeschlossen werden können. Listing 14 zeigt eine Policy in der Normalform, die zwei Alternativen bietet: <wsp:policy> <wsp:exactlyone> <wsp:all> <sp:basic256rsa15 /> </wsp:all> <wsp:all> <sp:tripledesrsa15 /> </wsp:all> </wsp:exactlyone> </wsp:policy> Listing 14 : Web Service Policy Die Struktur von Sicherheitsaussagen wird durch die WS-SecurityPolicy Spezifikation [27] definiert. WS-SecurityPolicy liefert ein umfangreiches Vokabular zur Beschreibung von Sicherheitsanforderungen eines Webservices. Listing 15 zeigt, dass für die Authentifizierung ein Username-Token erforderlich ist und, dass die Anfrage mit dem AES Algorithmus verschlüsselt werden muss. 16

17 <wsp:policy xmlns:wsp="..." xmlns:wsse="..."> <wsse:securitytoken wsp:usage="wsp:required"> <wsse:tokentype> wsse:usernametoken </wsse:tokentype> </wsse:securitytoken> <wsse:integrity wsp:usage="wsp:required"> <wsse:algorithm Type="wsse:AlgSignature" URI=" /xmlenc#aes" /> </wsse:integrity> </wsp:policy> Listing 15: Sicherheitspolicie für einen Webservices. Attachments werden durch WS-PolicyAttachment [29] definiert. Diese Spezifikation definiert wie WS-Policy-Audrücke den einzelnen Subjekten, die sie beschreiben sollen, zugeordnet werden. Ein Subjekt könnte beispielsweise ein beliebiges XML- Dokument, oder ein WSDL-Nachricht sein. Zusätzlich definiert WS- PolicyAttachment wie Policies in WSDL und UDDI eingebettet werden. 4.3 WS-Secure Conversation Die von Webservices angebotenen Mechanismen können nur einzelne Nachrichten sichern. Wenn mehrere Nachrichten ausgetauscht und gesichert werden sollen, bietet sich WS-SecureConversation [25,26] mit dem Sicherheitskontext-Token als geeignetes Mittel. dadurch reduziert sich der Aufwand, der durch das Sichern einzelner Nachrichten entstehen kann Sicherheitskontext-Token Das Sicherheitskontext-Token repräsentiert einen von zwei kommunizierenden Parteien gemeinsam genutzten Sicherheitskontext. In WS-Security und WS-Trust wird ein Token durch einen URI repräsentiert. Es enthält den Schlüssel, der die Integrität und/oder Vertraulichkeit der ausgetauschten Nachrichten gewährleistet aber keine Identitätsinformationen. Mithilfe eines Sicherheitskontext-Token wird das Erstellen eines neuen Schlüssels für jede Nachricht überflüssig, da eine sichere Sitzung geschaffen werden kann. Ein Sicherheitskontext-Token wird durch das <wsc:securitycontexttoken> Element beschrieben und hat die folgende Syntax: <wsc:securitycontexttoken wsu:id=..> <wsc:identifier>...</wsc:identifier> <wsc:instance>...</wsc:instance> </wsc:securitycontexttoken> Listing 16 :Syntax eines SecurityContextToken wsc:securitycontexttoken: Definiert ein Sicherheitstoken, das ein Sicherheitskontext beschreibt. 17

18 4 Weitere Sicherheitsmechanismen wsc:securitycontexttoken/wsc:identifier: Dieses nicht optionale Element identifiziert den Sicherheitskontext durch eine absolute URI. Jeder Sicherheitskontext-URI muss für Absender und Empfänger eindeutig sein. wsc:securitycontexttoken/wsc:instance: Wenn Kontexte erneuert werden und dadurch unterschiedliche Schlüssel gegeben werden, ist es notwendig, die unterschiedlichen Schlüssel zu identifizieren ohne den Aktuellen Schlüssel aufzudecken. Dieses optionale Element spezifiziert eine ID für das Element. Listing 17 zeigt die Verwendung eines Sicherheitskontext-Token: <?xml version="1.0" encoding="utf-8"?> <S11:Envelope xmlns:s11="..." xmlns:ds="..." xmlns:wsse="..." xmlns:wsu="..." xmlns:wsc="..."> <S11:Header>... <wsse:security> <wsc:securitycontexttoken wsu:id="myid"> <wsc:identifier>uuid:...</wsc:identifier> </wsc:securitycontexttoken> <ds:signature>... <ds:keyinfo> <wsse:securitytokenreference> <wsse:reference URI="#MyID"/> </wsse:securitytokenreference> </ds:keyinfo> </ds:signature> </wsse:security> </S11:Header> <S11:Body wsu:id="msgbody"> <tru:stocksymbol xmlns:tru=" </tru:stocksymbol> </S11:Body> </S11:Envelope> Listing 17 : Verwendung eines SecurityContextToken Das Element <S11:Header> definiert das SOAP Message Header. Das <wsse:security> Element repräsentiert den Sicherheitsblock und enthält die Sicherheitsinformationen. Das Sicherheitskontext-Token wird in diesem Fall durch das Element <wsse:securitytokenreference> spezifiziert. Innerhalb dieses Elementes spezifiziert das <wsc:identifier> Element die Identität dieses Kontexts. Die digitale Signatur wird durch das <ds:signature> Element spezifiziert und bezieht sich auf das Sicherheitskontext MYID. Das <wsse:securitytokenreference> Element bezeichnet den Schlüssel für diese Signatur. Es handelt sich um das Sicherheitskontext-Token. <S11:Body> definiert den Body dieser Nachricht. 18

19 Im folgenden Abschnitt wird erläutert, wie ein Sicherheitskontext-Token ausgegeben werden kann. Ausgeben von Sicherheitskontext-Token: Die Spezifikation definiert drei verschiedene Wege um Sicherheitskontext-Token auszugeben: 1. Ausgeben eines Sicherheitskontext-Token von einem Sicherheitstokendienst 2. Erzeugen eines Sicherheitskontext-Token von einer Kommunikationspartei 3. Erzeugen eines Sicherheitskontext-Token während einer Konversation bzw. einem Austausch. An dieser Stelle werden wir uns darauf beschränken zu erklären, wie ein Sichrehitskontext-Token durch einen Sicherheitstokendienst ausgegeben wird. Der Kontextinitiator sendet dem Sicherheitstokendienst eine wst:requestsecuritytoken Abfrage und verlangt einen neuen Sicherheitskontext- Token. Eine wst:requestsecuritytokenresponse wird zurückgegeben. Diese Antwort enthält das wst:requestedsecuritytoken Element, das den neuen erzeugten Token enthält, und wst:requestedprooftoken Element, das auf das Geheimnis dieses Kontext verweist. Abgeleitete Schlüssel Um das Signieren oder Verschlüsseln mehrerer Nachrichten mit demselben Schlüssel zu vermeiden und damit die Angriffschancen zu reduzieren, definiert die WS- SecureConversation Spezifikation einen weiteren Tokentyp zur Lösung dieses Problems, den Derived Key Token. Damit kann man den geheimen Schlüssel nicht direkt zum Sichern der Nachricht verwenden, sondern die abgeleitete Schlüsseln. Man kann z.b. für jede Nachricht ein Schlüsselpaar ableiten: einen für das Signieren und den anderen für das Verschlüsseln. Listing 18 zeigt ein Beispiel eines abgeleiteten Schlüsseltokens, das sich auf das Sicherheitskontext-Token (Security Context Token) bezieht und Bezeichnungs- und Nonce-Werte sowie eine Schlüssellänge enthält. <wsc:derivedkeytoken xmlns:wss=' xmlns:wsu=' xmlns:wsc=' Algorithm=' <wss:securitytokenreference> <wss:reference URI='#MySCT' ValueType=' /security/sc/sct'/> </wss:securitytokenreference> <wsc:length> 16 </wsc:length> <wsc:label> MyLabelText </wsc:label> 19

20 4 Weitere Sicherheitsmechanismen <wsc:nonce> CXrD7xEjbLQzN6au+RRfTQ== </wsc:nonce> </wsc:derivedkeytoken> Listing 18 : Beispiel eines abgeleiteten Schlüssels 4.4 WS-Federation Es gibt heutzutage Situationen in denen ein Webservice mehrere weitere Webservices aufruft, die in unterschiedlichen Sicherheitsdomänen aufgeteilt sind. In diesem Fall soll der Anfrager bei jedem Webservice seine Identität nachweisen und sich bestätigen lassen, bevor er die angebotenen Dienste aufrufen kann. Für diesen Zweck bietet die WS-Federation [31,20] ein Mechanismus, das auf WS-Policy, WS-Trust und WS-Security basiert. WS-Federation ermöglicht Zusammenschlüsse mehrerer Vertrauenszonen, indem Attribute, Authentifikation und Autorisation vereinigt werden. WS-Federation kann z.b. das Problem lösen, in dem eine Organisation Kerberos und eine andere X.509 für die Kommunikation verwenden will. Abbildung 6: Basic STS aus WS-Federation Spezifikation Abbildung 5 veranschaulicht eine von vielen Möglichkeiten, wie das WS-Trust Modell eingesetzt wird, um eine Token-Vereinigung zu ermöglichen. In diesem Beispiel wird der Sicherheitstoken (1) vom Anfrager-Vertrauensbereich benutzt, um den Sicherheitstoken vom Ressourcen-Vertrauensbereich (2) anzueignen, um auf dem Ressourcenservice (3) zugreifen zu können. Der Token könnte zwischen den beiden Trustbereichen ausgetaucht werden oder z.b. Cross- Zertifiziert. Ein anderes Szenario könnte ein Validierungssevice benutzen um, unter Nutzung vom Ressoucenanbieter- 20

21 Token, den Sicherheitstoken vom Anfrager zu überprüfen. Beide Szenarien benutzen Direkt Trust. Weitere Szenarien in der Spezifikation schildern andere Möglichkeiten mit Indirekt Trust. Der Prozess zum Austausch von Sicherheitstokens zwischen einem Webservice Anfrager und einem Webservice Anbieter in verschiedenen Sicherheitsdomänen könnte folgendermaßen aussehen: 1. Policy erwerben: Falls der Anfrager über keine Policy für den gewünschten Dienst verfügt, kann er eine Policy mit dem WS-MetadataExchange beantragen. WS-MetadataExchange ermöglicht es, Informationen direkt unter Benutzung von WSDL zu erwerben oder UDDI Service benutzen, der die Informationen für mehrere Services sammelt. 2. Rückgabe einer Policy: Der Webservice liefert eine Policy mit dem WS- MetadataExchange zurück. 3. Request eines Sicherheitstoken: In diesem Schritt beantragt der Anfrager ein Sicherheitstoken vom Anfrager-Sicherheitstokendienst mit dem <RequestSecurityToken>, wie wir unter WS-Trust gesehen haben. 4. Ausgabe eines Sicherheitstoken: Der Sicherheitstokendienst gibt ein Sicherheitstoken aus, wie unter WS-Trust beschrieben ist: <RequestSecurityTokenResponse> und optional <RequestedProofToken>. 5. Request eines Sicherheitstoken: In diesem Schritt beantragt der Anfrager ein Sicherheitstoken vom Webservices-Sicherheitstokendienst mit dem <RequestSecurityToken>, wie unter WS-Trust beschrieben ist. 6. Rückgabe eines Sicherheitstoken: Der Webservice Sicherheitstokendienst liefert ein Token, wie unter WS-Trust beschrieben ist: <RequestSecurityTokenResponse> und optional <RequestedProofToken>. 7. Absenden von sicherer Anfrage: Der Anfrager sendet dann dem Web Service eine sichere Anfrage unter Verwendung dieses Tokens, wie in WS-Security beschrieben ist. 8. Rückgabe des Resultat: In diesem Schritt wird das Ergebnis vom Webservice unter Nutzung seines Sicherheitstoken, bereitgestellt. 4.5 WS-Authorization WS-Authorization [34] beschreibt, wie Autorisierungsdaten und policies in einem Webservices spezifiziert und verwaltet werden. Das Ziel ist zu beschreiben, wie Claims innerhalb des Sicherheitstokens spezifiziert und wie diese am Endpunkt interpretiert werden. WS-Authorization gewährt Flexibilität und Erweiterbarkeit ohne das Autorisierungsformat oder die Autorisierungssprache zu verletzen. In Webservice Sicherheitsmodell, das in WS-Authorization definiert wird, überprüft ein Webservice, ob eine ankommende Anfrage mit einer Menge von Claims, wie Namen, Privileg, Fähigkeit usw., und Kontextinformationen, wie aktuelle Uhrzeit usw., qualifiziert ist, um den Zielservice aufzurufen oder die gewünschte Operation auszuführen. Falls nicht, dann wird die Anfrage ignoriert oder zurückgewiesen. Autorisierungsüberprüfung wird durch einen Autorisierungsdienst durchgeführt, das ist ähnlich wie der Security Token Service (STS), das in WS-Trust definiert ist. Ein Webservice kann den Autorisierungsdienst mit einer Menge von Claims und 21

22 5 Einige Implementierungen Sicherheitstoken aufrufen. Daraufhin sucht der Autorisierungsdienst die gültige Authorization Policie und ermittelt, ob der Zugriff gewährt oder verweigert werden muss. Er schickt das Resultat der Authorization zurück, entweder durch Herausgeben eines Authorization-Tokens oder indem er mit einigen Nachrichten antwortet. Das Authorization-Token beweist die Rechte, Privilegien oder Fähigkeiten des Besitzers, kann aber auch weitere Semantik enthalten, wie die Gültigkeit (gültig oder nicht gültig) vom Authorization-Token und die Aufzählung der Rechte des Anfragers. Authorization-Token ist einer der Sicherheitstokens, die in WSS: SOAP Message Security definiert ist. Der entworfene Mechanismus für die Herausgabe und den Austausch der Sicherheitstoken in WS-Trust ist wieder verwendbar in WS-Authorization Spezifikation. 4.6 WS-Privacy WS-Privacy [34] ist ein Teil des Security Roadmap von Microsoft und IBM, das im April 2002 veröffentlicht wurde. Die Spezifikation ist noch nicht veröffentlicht. Webservice Anbieter können ihre individuellen Sicherheitseinstellungen in Form von Datenschutz Policies festlegen und von allen eingehenden Anfragen die Einhaltung von dieser Policies verlangen. In der WS-Privacy Spezifikation werden nur die Syntax und Semantik beschrieben, wie diese Policies in einem Web Service eingebunden werden. Dafür definiert diese Spezifikation keine neuen Policies- Sprachen, sondern stellt nur Mittel zur Verfügung um diese Policies mit einem Webservice zu verbinden. WS-Privacy definiert das Zusammenspiel zwischen, WS- Trust, WS-Policy und WS-Security. 5 Einige Implementierungen Nachdem in den letzen Abschnitten das WS-Security Framework und die darauf basierende Spezifikationen näher erläutert wurden, ist es jetzt Zeit einige Implementierung für diese Spezifikationen näher zu untersuchen. 5.1 WSE 3.0 Webservice Enhancements (WSE) [35, 36, 37], mittlerweile in Version 3.0, definiert eine Erweiterung der.net Framework und soll Entwickler bei der Implementierung und Deployement von sicheren Webservices unterstützen. Mit WSE 3.0 kann eine SOAP Nachricht signiert, verschlüsselt und authentifiziert werden. Für die Authentifizierung eines Benutzers kann entweder die Angabe eines Benutzernamen mit oder ohne Passwort als auch Kerberos Tickes oder X-509 Zertifikate verwendet werden. Außerdem implementiert WSE 3.0 die neuste WS-Trust Spezifikation. Das Ausstellen, Erneuern und Überprüfen von Sicherheitstoken werden durch eine entsprechende Klasse verarbeitet. Es bietet sich auch die Möglichkeit eine lange sichere Kommunikation mit WS-SecureConversation zu etablieren. Die Einbettung 22

23 der Sicherheitsanforderungen für SOAP Nachrichten kann entweder durch das WSE Sicherheitseinstellungstools, durch das manuelle Hinzufügen von Policies Elemente und Attribute in die Policy Datei oder durch Implementierung erfolgen. Dazu wird eine Klasse von Microsoft.Web.Services3.Design.Policy abgeleitet. Listing 18 zeigt, wie eine KerberosAssertion erzeugt und in der Policy hinzugefügt wird. using System; using System.Web; using System.Web.Services; using System.Web.Services.Protocols; using Microsoft.Web.Services3.Design; using Microsoft.Web.Services3.Security.Tokens.Kerberos; using Microsoft.Web.Services3.Security.Tokens; //Class that derives from public class Microsoft.Web.Services3.Design.Policy public class WebServiceSecurity: Policy{ public WebServiceSecurity():base(){ Assert(); } private void Assert(){ // Create a new instance of a KerberosAssertion type. KerberosAssertion K_assertion = new KerberosAssertion(); //Specify a security token provider for the Web service's security credentials. K_assertion.KerberosTokenProvider = New KerberosServerContext(true, ImpersonationLevel.Impersonation); //Add the assertion to the Assertions of the Policy this.assertions.add(k_assertion); }} Listing 19: Sicherheits-Unterstützung mit WSE 5.2 Systinet Das Systinet [38] Server Webservices Security Framework von der Firma Systinet ermöglicht auch die Implementierung von sicheren Webservices. Das Framework stellt den Entwicklern zahlreiche Funktionalitäten, wie die Authentifizierung, Autorisierung und Integrität von Nachrichten sowie weitere Sicherheitsanforderungen. Das Systinet Server Webservice Framework besteht aus drei verschiedene Kategorien, wie das folgende Bild zeigt: 23

24 5 Einige Implementierungen Abbildung 6: Systinet Server Security Categories Web Service Level: Definiert Sicherheitseigenschaften, die in SOAP Nachrichten integriert werden können, wie z.b. Authentifizierung und Autorisierung. XML Security Level: Definiert die Sicherheitseigenschaften, die auf XML basieren, wie z.b. XML Encryption, XML Signatur. Low-level security: Definiert Sicherheitseigenschaften und Technologien, die für die Implementierung der oben genanten Sicherheitseigenschaften notwendig sind. Das folgende Listing zeigt, wie ein Username-Token mit Systinet erzeugt werden kann: public class UsernameToken extends SecurityToken { // create service client instance ServiceClient serviceclient = ServiceClient.create(" // authenticate client and set the credentials Credentials creds = WaspSecurity.acquireClientCredentials("Chris", "sirhc", "WS-Security"); WaspSecurity.setCredentials(serviceClient, new Credentials[]{creds}); WaspSecurity.setInitiatingProvider(serviceClient, "WS-Security"); // create service proxy ServiceSoap svc = (ServiceSoap) serviceclient.createproxy(servicesoap.class); // create new call security configuration MessageSecurity ms = new MessageSecurity(); // create username token (password will be sent in plaintext) UsernameToken usernametoken = new UsernameToken(PasswordOption.TEXT); // add username token to message security ms.addtoken(usernametoken); 24

25 // set call security configuration ms.setcallsecurity(serviceclient); // invoke service method Svc.ping("EchoString"); } Listing 20: Benutzung der Klasse UsernameToken in Systinet Das folgende Listing zeigt, wie ein X509Token erzeugt werden kann: public class X509Token extends SecurityToken // create X509 token with current credentials X509Token token = new X509Token(); // create context security configuration MessageSecurity ms = new MessageSecurity(); // add the token to external tokens in context security configuration ms.addexternaltoken(token); // set context security configuration ms.setcontextsecurity(...); // ServiceClient or ServiceEndpoint instance } Listing 21: Benutzung der Klasse X509Token in Systinet 5.3 WSS4J WSS4J [39] in der Version wurde von Apache Foundation veröffentlicht. WSS4J ist eine Java basierte API. Sie ist eine Implementierung von OASIS Webservices Security (WS-Security) und verwendet Apache Axis und XML-Security. WSS4J kann viele Sicherheitsfeatures generieren bzw. bearbeiten, wie XML-Security, XML Signature, XML Encryption sowie UsernameTokens und SAML Tokens. Er unterstützt auch die Einbindung von X.509 Zertifikaten. WSS4J kann als Library benutzt werden, um eine Schnittstelle für die Bearbeitung von WS-Security anzubieten. WSS4J API kann direkt aufgerufen werden, um einen WS-Security Header zu erzeugen oder zu bearbeiten. Z.B. zum Signieren von SOAP Envelope bietet er das Packet org.apache.ws.security.message.wssignenvelope, zum Verschlüsseln wird org.apache.ws.security.message.wsencryptbody benutzt, zum einbinden eines UsernameToken in einem SOAP Envelope wird org.apache.ws.security.message.wsaddusernametoken verwendet usw. Listing 22 zeigt wie ein SOAP Body signiert wird: Document envelope =... WSSignEnvelope signer = new WSSignEnvelope(); 25

26 5 Einige Implementierungen Crypto crypto = CryptoFactory.getInstance("crypto.properties"); Vector parts = new Vector(); WSEncryptionPart part = new WSEncryptionPart(soapConstants.getBodyQName().getLocalPart(), soapconstants.getenvelopeuri(), "Content"); parts.add(part); // this is optional since the body is signed by default signer.setparts(parts); envelope=signer.build(envelope, crypto); Listing 22: Signieren eines SOAP Body mit WSS4J Listing 23, wie ein Body verschlüsselt werden kann: Document envelope =... WSEncryptBody encryptor = new WSEncryptBody(); Crypto crypto = CryptoFactory.getInstance("crypto.properties"); Vector parts = new Vector(); WSEncryptionPart part = new WSEncryptionPart(soapConstants.getBodyQName().getLocalPart(), soapconstants.getenvelopeuri(), "Content"); parts.add(part); // this is optional since the body is encrypted by default encryptor.setparts(parts); envelope = encryptor.build(envelope, crypto); Listing 23: Verschlüsseln eines SOAP Body mit WSS4J 6 Fazit Webservices sind heutzutage immer das Ziel von Angriffen geworden. Existierende Technologien, wie SSL oder IPSEC können die Sicherheitsanforderungen, wie Integrität, Authentizität und Vertraulichkeit gewährleisten. Sie sind aber nicht ausreichend um Webservices zu sichern, da sie keine Ende-zu-Ende-Sicherheit anbieten. WS-Security bietet ein erweiterbaren Framework und eine flexible Syntax zur Implementierung von verschiedenen Sicherheitsmechanismen. Die WS-Security Spezifikation basiert auf bestehende XML-Sicherheitmechanismen, wie XML Encryption, XML Signature und XML-Canonicalization, und beschreibt, wie Sicherheitstokens in einer SOAP Nachricht eingebunden werden. Dieses Framework stellt nur Mechanismen zur Lösung von Sicherheitsproblemen zur Verfügung, bietet 26