Sicherheit in Webservices

Save this PDF as:
 WORD  PNG  TXT  JPG

Größe: px
Ab Seite anzeigen:

Download "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

Sicherheit in Web Services. Seminar Service-orientierte Software Architekturen Melanie Storm

Sicherheit in Web Services. Seminar Service-orientierte Software Architekturen Melanie Storm Sicherheit in Web Services Seminar Service-orientierte Software Architekturen Melanie Storm Agenda Motivation Fallbeispiel WS-Security XML Encryption XML Signature WS-Policy WS-SecurityPolicy WS-Trust

Mehr

3. Web Service Security 3.1 WS-Security. Jörg Schwenk Lehrstuhl für Netz- und Datensicherheit

3. Web Service Security 3.1 WS-Security. Jörg Schwenk Lehrstuhl für Netz- und Datensicherheit XML- und Webservice- Sicherheit 3. Web Service Security 3.1 WS-Security Gliederung 1. SOAP 2. WS-Security: Der SOAP Security Header 3. Security Tokens in WS-Security S 4. XML Signature in WS-Security 5.

Mehr

Web Service Security

Web Service Security Informatik Masterstudiengang SS 2005 Anwendungen I Web Service Security Thies Rubarth Übersicht Einleitung Secure Socket Layer XML Encryption & XML Signature WS-* WS-Security WS-Policy WS-Trust Angebot

Mehr

Service-Orientierte Architekturen

Service-Orientierte Architekturen Hochschule Bonn-Rhein-Sieg Service-Orientierte Architekturen Kapitel 7: Web Services IV Exkurs über Sicherheitsanforderungen Vorlesung im Masterstudiengang Informatik Sommersemester 2010 Prof. Dr. Sascha

Mehr

Analyse von Sicherheitaspekten in Service-orientierten Architekturen

Analyse von Sicherheitaspekten in Service-orientierten Architekturen Analyse von Sicherheitaspekten in Service-orientierten Architekturen Vortragende: Jia Jia Betreuer: Dipl.-Inf. Matthias Lehmann Dresden,10.12.2009 10.12.2009 Analyse von Sicherheitaspekten in SOA 1 Gliederung

Mehr

Web Service Security

Web Service Security Hochschule für Angewandte Wissenschaften Hamburg Fachbereich Elektrotechnik und Informatik SS 2005 Masterstudiengang Anwendungen I Kai von Luck Web Service Security Thies Rubarth rubart_t@informatik.haw-hamburg.de

Mehr

Allgemeine Übersicht WS-Security

Allgemeine Übersicht WS-Security Allgemeine Übersicht WS-Security Alexander Grünke Teleseminar: Web Services - Sommersemester 04 Betreuer: Jochen Dinger 06.07.2004 Inhalt Einleitung und Motivation Sicherheitsanforderungen an Web-Services

Mehr

WS-Security. Thies Rubarth. Sicherheitskonzepte in global verteilten Anwendungen. 21. Sep 2007 ACM/GI Localgroup #216

WS-Security. Thies Rubarth. Sicherheitskonzepte in global verteilten Anwendungen. 21. Sep 2007 ACM/GI Localgroup #216 WS-Security Sicherheitskonzepte in global verteilten Anwendungen Thies Rubarth 21. Sep 2007 ACM/GI Localgroup #216 Thies Rubarth, M.Sc. (Informatik) IT Berater Jahrgang 1979 Anwendungsentwicklung seit

Mehr

Sicherheitsaspekte von Web Services. Hauptseminar Rechnernetze

Sicherheitsaspekte von Web Services. Hauptseminar Rechnernetze Sicherheitsaspekte von Web Services Hauptseminar Rechnernetze Stefan Hennig sh790883@inf.tu-dresden.de 21. Januar 2005 Gliederung Einführung Überblick Sicherheit auf Netzwerk- und Transportebene XML-Sicherheit

Mehr

3. Web Service Security 3.3 WS-Trust. Jörg Schwenk Lehrstuhl für Netz- und Datensicherheit

3. Web Service Security 3.3 WS-Trust. Jörg Schwenk Lehrstuhl für Netz- und Datensicherheit XML- und Webservice- Sicherheit 3. Web Service Security 3.3 WS-Trust Gliederung 1. WS-Trust 2. WS-Trust: X.509 CustomToken 3. WS-Trust: Kerberos X.509 Literatur: J. Rosenberg and D. Remy, Securing Web

Mehr

SAX-basierte Validierung von WS-Security-angereicherten SOAP- Nachrichten gegen eine Security Policy

SAX-basierte Validierung von WS-Security-angereicherten SOAP- Nachrichten gegen eine Security Policy SAX-basierte Validierung von WS-Security-angereicherten SOAP- Nachrichten gegen eine Security Policy Ralph Herkenhöner Arbeitsgruppe Kommunikationssysteme Institut für Informatik Christian-Albrechts-Universität

Mehr

Vorlesung "SOA Entwicklung verteilter Systeme auf Basis serviceorientierter Architekturen" 10. Sicherheitsaspekte (Fortsetzung)

Vorlesung SOA Entwicklung verteilter Systeme auf Basis serviceorientierter Architekturen 10. Sicherheitsaspekte (Fortsetzung) Vorlesung "SOA Entwicklung verteilter Systeme auf Basis serviceorientierter Architekturen" 10. Sicherheitsaspekte (Fortsetzung) Dr.-Ing. Iris Braun Gliederung WS-Security Authentifizierung Single-Sign-On

Mehr

Sicherheitsaspekte in Service Orientierten Architekturen. Eike Falkenberg Sommersemester 2006 Anwendungen I

Sicherheitsaspekte in Service Orientierten Architekturen. Eike Falkenberg Sommersemester 2006 Anwendungen I Sicherheitsaspekte in Service Orientierten Architekturen Eike Falkenberg Sommersemester 2006 Anwendungen I Agenda SOA? Web Services? Sicherheitsrisiko Web Services Web Services & Sicherheit Sichere SOAs

Mehr

Web Service Security Aktuelle Themen der Informatik

Web Service Security Aktuelle Themen der Informatik Aktuelle Themen der Informatik Damian Schlager CN8 Inhalt 1 Einführung...3 1.1 Anforderungen an die Sicherheit...3 1.2 Erweiterung der Sicherheitsanforderungen an XML...3 1.3 Einordnung bisheriger Sicherheitsmechanismen...3

Mehr

Sicherheitskonzepte in SOA auf Basis sicherer Webservices

Sicherheitskonzepte in SOA auf Basis sicherer Webservices HAW Hamburg Seminarvortrag - 16.12.2005 Thies Rubarth Folie 1 Sicherheit machen wir später...... wie hätt's auch anders sein sollen? Sicherheitskonzepte in SOA auf Basis sicherer Webservices Thies Rubarth

Mehr

Web Services und Sicherheit

Web Services und Sicherheit Autoren: Kristian Kottke, Christian Latus, Cristina Murgu, Ognyan Naydenov Folie 1 Agenda Sicherheitsprobleme von Web Services Lösungsansätze Sicherheitsmechanismen des Java Application Servers Autorisation

Mehr

SEMINARARBEIT IM FACHBEREICH WIRTSCHAFTSINFORMATIK

SEMINARARBEIT IM FACHBEREICH WIRTSCHAFTSINFORMATIK SEMINARARBEIT IM FACHBEREICH WIRTSCHAFTSINFORMATIK Service-orientierte Architekturen Eingereicht von Melanie Storm Schulstr. 19 22880 Wedel Fachrichtung B_Winf Matrikelnummer 2914 Fachsemester 4 Eingereicht

Mehr

Geschäftsführer, OPTIMAbit GmbH. OPTIMA Business Information Technology GmbH ist eine Beratungsfirma, spezialisiert auf

Geschäftsführer, OPTIMAbit GmbH. OPTIMA Business Information Technology GmbH ist eine Beratungsfirma, spezialisiert auf SOA Security Dr. Bruce Sams Geschäftsführer, OPTIMAbit GmbH Über OPTIMA OPTIMA Business Information Technology GmbH ist eine Beratungsfirma, spezialisiert auf Sicherheit für Anwendungen und Infrastrukturen

Mehr

Auszug aus der Schulung Web Services Sicherheit

Auszug aus der Schulung Web Services Sicherheit Auszug aus der Schulung Web Services Sicherheit Dieses Dokument ist ein Auszug aus unserem Skript zur Schulung Web Services Sicherheit. Es dient als Beispiel für unsere Kursunterlagen. Thomas Bayer Nikolausstraße

Mehr

Performance Untersuchung von WS Security Implementierungen in interoperablen Umgebungen

Performance Untersuchung von WS Security Implementierungen in interoperablen Umgebungen Performance Untersuchung von WS Security Implementierungen in interoperablen Umgebungen Master Thesis Outline Eike Falkenberg Im Master Studiengang Informatik Wintersemester 2006 / 2007 Department Informatik

Mehr

XML Signature (DSig) Einführung, Anwendungsbeispiele und Ausblick. heiko@vegan-welt.de GPN4: 22.05.2005

XML Signature (DSig) Einführung, Anwendungsbeispiele und Ausblick. heiko@vegan-welt.de GPN4: 22.05.2005 XML Signature (DSig) Einführung, Anwendungsbeispiele und Ausblick GPN4: 22.05.2005 Übersicht Wofür Signaturen? Wieso ein weiteres Signaturverfahren? Grundlagen Signatur-Typen Juristische Aspekte von Signaturen

Mehr

Containerformat Spezifikation

Containerformat Spezifikation Containerformat Spezifikation Version 1.0-09.05.2011 Inhaltsverzeichnis 0 Einführung... 4 0.1 Referenzierte Dokumente... 4 0.2 Abkürzungen... 4 1 Containerformat... 5 1.1 Aufbau des Container-Headers...

Mehr

Containerformat Spezifikation

Containerformat Spezifikation Containerformat Spezifikation Version 1.1-21.02.2014 Inhaltsverzeichnis 0 Einführung... 4 0.1 Referenzierte Dokumente... 4 0.2 Abkürzungen... 4 1 Containerformat... 5 1.1 Aufbau des Container-Headers...

Mehr

XML-Sicherheitsdienste für das Netzwerk der Global Biodiversity Information Facility GBIF

XML-Sicherheitsdienste für das Netzwerk der Global Biodiversity Information Facility GBIF XML-Sicherheitsdienste für das Netzwerk der Global Biodiversity Information Facility GBIF Dipl.-Inf. Lutz Suhrbier Prof. Dr.-Ing. Robert Tolksdorf Dipl.-Inf. Ekaterina Langer Freie Universität Berlin Institut

Mehr

On breaking SAML. Be Whoever You Want to Be. von David Foerster

On breaking SAML. Be Whoever You Want to Be. von David Foerster On breaking SAML Be Whoever You Want to Be von David Foerster Gliederung Übersicht & Motivation XML Signature Wrapping Attacks Vorstellung Gegenmaßnahmen Zusammenfassung 2 Übersicht & Motivation SAML Übersicht

Mehr

Dr. Eric Dubuis* CHOOSE Talk / SWEN Vortragsreihe Berner Fachhochschule. www.swen-network.ch. Inhalt. Wer sind wir?

Dr. Eric Dubuis* CHOOSE Talk / SWEN Vortragsreihe Berner Fachhochschule. www.swen-network.ch. Inhalt. Wer sind wir? SWEN Fachverein Ziele: Förderung der Vernetzung und Zusammenarbeit zwischen den (Fach)Hochschulen und der Wirtschaft Stärkung des Software Engineerings in schweizerischen Klein- und Mittelunternehmen (KMU)

Mehr

Informatik für Ökonomen II HS 09

Informatik für Ökonomen II HS 09 Informatik für Ökonomen II HS 09 Übung 5 Ausgabe: 03. Dezember 2009 Abgabe: 10. Dezember 2009 Die Lösungen zu den Aufgabe sind direkt auf das Blatt zu schreiben. Bitte verwenden Sie keinen Bleistift und

Mehr

Enterprise Applikation Integration und Service-orientierte Architekturen. 09 Simple Object Access Protocol (SOAP)

Enterprise Applikation Integration und Service-orientierte Architekturen. 09 Simple Object Access Protocol (SOAP) Enterprise Applikation Integration und Service-orientierte Architekturen 09 Simple Object Access Protocol (SOAP) Anwendungsintegration ein Beispiel Messages Warenwirtschaftssystem Auktionssystem thats

Mehr

OAuth Ein offener Standard für die sichere Autentifizierung in APIs

OAuth Ein offener Standard für die sichere Autentifizierung in APIs OAuth Ein offener Standard für die sichere Autentifizierung in APIs Max Horváth, Andre Zayarni, Bastian Hofmann 1 Vorstellung der Speaker 2 Was ist OAuth?? 3 Was ist OAuth? OAuth ermöglicht dem Endnutzer

Mehr

Allgemeine Übersicht zu WS-Security

Allgemeine Übersicht zu WS-Security Allgemeine Übersicht zu WS-Security Seminararbeit Betreuer: Dipl.-Inform. Jochen Dinger Universität Karlsruhe (TH) vorgelegt am Lehrstuhl für Praktische Informatik Prof. Dr. W. Effelsberg Universität Mannheim

Mehr

Semantic Web Technologien. Security and Trust. Sebastian Henke. Betreuer: Mark Giereth VIS 06

Semantic Web Technologien. Security and Trust. Sebastian Henke. Betreuer: Mark Giereth VIS 06 Semantic Web Technologien Security and Trust Sebastian Henke Betreuer: Mark Giereth Überblick Einführung Security Trust Verschlüsselung Pre-Shared-Key-Verfahren Public-Key-Verfahren Digitale Signatur Funktionsweise

Mehr

Multicast Security Group Key Management Architecture (MSEC GKMArch)

Multicast Security Group Key Management Architecture (MSEC GKMArch) Multicast Security Group Key Management Architecture (MSEC GKMArch) draft-ietf-msec-gkmarch-07.txt Internet Security Tobias Engelbrecht Einführung Bei diversen Internetanwendungen, wie zum Beispiel Telefonkonferenzen

Mehr

Wiederholung: Beginn

Wiederholung: Beginn B) Webserivces W3C Web Services Architecture Group: "Ein Web Service ist eine durch einen URI eindeutige identifizierte Softwareanwendung, deren Schnittstellen als XML Artefakte definiert, beschrieben

Mehr

Webservices. 1 Einführung 2 Verwendete Standards 3 Web Services mit Java 4 Zusammenfassung. Hauptseminar Internet Dienste

Webservices. 1 Einführung 2 Verwendete Standards 3 Web Services mit Java 4 Zusammenfassung. Hauptseminar Internet Dienste Hauptseminar Internet Dienste Sommersemester 2004 Boto Bako Webservices 1 Einführung 2 Verwendete Standards 3 Web Services mit Java 4 Zusammenfassung Was sind Web Services? Web Services sind angebotene

Mehr

Norm 260 Sicherheitsmechanismen

Norm 260 Sicherheitsmechanismen 1 Norm 260 Sicherheitsmechanismen 2 3 Release und Version Release 1, Version 5.0, vom 15.04.2014 4 5 Status Offizielle Norm 6 7 Editor Geschäftsstelle BiPRO e.v. 8 9 10 11 12 13 14 15 Autoren Dr. Thomas

Mehr

Sicherheit in Netzwerken. Leonard Claus, WS 2012 / 2013

Sicherheit in Netzwerken. Leonard Claus, WS 2012 / 2013 Sicherheit in Netzwerken Leonard Claus, WS 2012 / 2013 Inhalt 1 Definition eines Sicherheitsbegriffs 2 Einführung in die Kryptografie 3 Netzwerksicherheit 3.1 E-Mail-Sicherheit 3.2 Sicherheit im Web 4

Mehr

Netzsicherheit I, WS 2008/2009 Übung 12. Prof. Dr. Jörg Schwenk 20.01.2009

Netzsicherheit I, WS 2008/2009 Übung 12. Prof. Dr. Jörg Schwenk 20.01.2009 Netzsicherheit I, WS 2008/2009 Übung 12 Prof. Dr. Jörg Schwenk 20.01.2009 Aufgabe 1 1 Zertifikate im Allgemeinen a) Was versteht man unter folgenden Begriffen? i. X.509 X.509 ist ein Standard (Zertifikatsstandard)

Mehr

Norm 260 Sicherheitsmechanismen

Norm 260 Sicherheitsmechanismen 1 Norm 260 Sicherheitsmechanismen 2 3 4 Release und Version Release 2 Version 2.5.0 vom 15.04.2014, NAUS-Beschluss vom 27.03.2014 5 6 7 8 9 10 Status Arbeitsentwurf vom 12.08.2008 Potenzielle Norm vom

Mehr

Programmiertechnik II

Programmiertechnik II X.509: Eine Einführung X.509 ITU-T-Standard: Information Technology Open Systems Interconnection The Directory: Public Key and attribute certificate frameworks Teil des OSI Directory Service (X.500) parallel

Mehr

Allgemeine Erläuterungen zu

Allgemeine Erläuterungen zu en zu persönliche Zertifikate Wurzelzertifikate Zertifikatssperrliste/Widerrufsliste (CRL) Public Key Infrastructure (PKI) Signierung und Verschlüsselung mit S/MIME 1. zum Thema Zertifikate Zertifikate

Mehr

Identity Management und Berechtigungen

Identity Management und Berechtigungen LMU Ludwig- Maximilians- Universität München Lehr- und Forschungseinheit für Programmierung und Softwaretechnik Vorlesung am 23.6.2009 Serviceorientiertes E-Government Identity Management und Berechtigungen

Mehr

.NET-Networking 2 Windows Communication Foundation

.NET-Networking 2 Windows Communication Foundation .NET-Networking 2 Windows Communication Foundation Proseminar Objektorientiertes Programmieren mit.net und C# Fabian Raab Institut für Informatik Software & Systems Engineering Agenda Grundproblem Bestandteile

Mehr

Whitepaper. EDIFACT-Signatur-, Verschlüsselungs- und Mailcockpit

Whitepaper. EDIFACT-Signatur-, Verschlüsselungs- und Mailcockpit Whitepaper EDIFACT-Signatur-, Verschlüsselungs- und Mailcockpit Funktionsumfang: Plattform: Verschlüsselung, Signierung und email-versand von EDIFACT-Nachrichten des deutschen Energiemarktes gemäß der

Mehr

Federated Identity Management

Federated Identity Management Federated Identity Management Verwendung von SAML, Liberty und XACML in einem Inter Campus Szenario d.marinescu@gmx.de 1 Fachbereich Informatik Inhalt Grundlagen Analyse Design Implementierung Demo Zusammenfassung

Mehr

E-Mail-Verschlüsselung

E-Mail-Verschlüsselung E-Mail-Verschlüsselung In der Böllhoff Gruppe Informationen für unsere Geschäftspartner Inhaltsverzeichnis 1 E-Mail-Verschlüsselung generell... 1 1.1 S/MIME... 1 1.2 PGP... 1 2 Korrespondenz mit Böllhoff...

Mehr

Verteilte Systeme. 10.1 Unsicherheit in Verteilten Systemen

Verteilte Systeme. 10.1 Unsicherheit in Verteilten Systemen Verteilte Systeme Übung 10 Jens Müller-Iden Gruppe PVS (Parallele und Verteilte Systeme) Institut für Informatik Westfälische Wilhelms-Universität Münster Sommersemester 2007 10.1 Unsicherheit in Verteilten

Mehr

vorab noch ein paar allgemeine informationen zur de-mail verschlüsselung:

vorab noch ein paar allgemeine informationen zur de-mail verschlüsselung: Kurzanleitung De-Mail Verschlüsselung so nutzen sie die verschlüsselung von de-mail in vier schritten Schritt 1: Browser-Erweiterung installieren Schritt 2: Schlüsselpaar erstellen Schritt 3: Schlüsselaustausch

Mehr

Verteilte Systeme. Übung 10. Jens Müller-Iden

Verteilte Systeme. Übung 10. Jens Müller-Iden Verteilte Systeme Übung 10 Jens Müller-Iden Gruppe PVS (Parallele und Verteilte Systeme) Institut für Informatik Westfälische Wilhelms-Universität Münster Sommersemester 2007 10.1 Unsicherheit in Verteilten

Mehr

1 Dataport 12.Juli 2007 Internationale Standards zu Identity Management. Deckblatt. Harald Krause

1 Dataport 12.Juli 2007 Internationale Standards zu Identity Management. Deckblatt. Harald Krause 1 Dataport 12.Juli 2007 Internationale Standards zu Identity Management Deckblatt Bremen, E-Government in medias res, 12. Juli 2007 Internationale Standards zu Identity Management 3 Dataport 12.Juli 2007

Mehr

!"#$"%&'()*$+()',!-+.'/',

!#$%&'()*$+()',!-+.'/', Soziotechnische Informationssysteme 7. OAuth, OpenID und SAML Inhalte Motivation OAuth OpenID SAML 4(5,12316,7'.'0,!.80/6,9*$:'0+$.;.,&0$'0, 3, Grundlagen Schützenswerte Objekte Zugreifende Subjekte Authentifizierung!

Mehr

Thema: Web Services. Was ist ein Web Service?

Thema: Web Services. Was ist ein Web Service? Willkommen zum Component Ware Seminar Thema: Achim Grimm & Fabian Unterschütz Folie 1 Was ist ein Web Service? Web Services sind selbstbeschreibende, modulare Softwarekomponenten im Internet, die sich

Mehr

Norm 260 Sicherheitsmechanismen

Norm 260 Sicherheitsmechanismen 1 Norm 260 Sicherheitsmechanismen 2 3 Release und Version Release 1, Version 4.0, vom 19. Juni 2007 4 5 Status Offizielle Norm 6 7 Editor Dr. Thomas Kippenberg, NÜRNBERGER 8 9 10 11 12 13 14 Autoren Dr.

Mehr

2.4 Hash-Prüfsummen Hash-Funktion message digest Fingerprint kollisionsfrei Einweg-Funktion

2.4 Hash-Prüfsummen Hash-Funktion message digest Fingerprint kollisionsfrei Einweg-Funktion 2.4 Hash-Prüfsummen Mit einer Hash-Funktion wird von einer Nachricht eine Prüfsumme (Hash-Wert oder message digest) erstellt. Diese Prüfsumme besitzt immer die gleiche Länge unabhängig von der Länge der

Mehr

(c) 2014, Peter Sturm, Universität Trier

(c) 2014, Peter Sturm, Universität Trier Soziotechnische Informationssysteme 6. OAuth, OpenID und SAML Inhalte Motivation OAuth OpenID SAML 1 Grundlagen Schützenswerte Objekte Zugreifende Subjekte Authentifizierung Nachweis einer behaupteten

Mehr

Konfigurieren der Netzwerksicherheit mit Hilfe von PKI (Public Key Infrastructure)

Konfigurieren der Netzwerksicherheit mit Hilfe von PKI (Public Key Infrastructure) Unterrichtseinheit 5: Konfigurieren der Netzwerksicherheit mit Hilfe von PKI (Public Key Infrastructure) Verschlüsselung mit öffentlichen Schlüsseln ist eine bedeutende Technologie für E- Commerce, Intranets,

Mehr

Verteilte Systeme: Übung 4

Verteilte Systeme: Übung 4 Verteilte Systeme: Übung 4 WSDL und SOAP Oliver Kleine Institut für Telematik https://www.itm.uni-luebeck.de/people/kleine SOAP Nachrichten Serialisierung in XML Root-Element einer SOAP Nachricht ist

Mehr

Java und XML 2. Java und XML

Java und XML 2. Java und XML Technische Universität Ilmenau Fakultät für Informatik und Automatisierung Institut für Praktische Informatik und Medieninformatik Fachgebiet Telematik Java und XML Hauptseminar Telematik WS 2002/2003

Mehr

WSDL. Web Services Description Language. André Vorbach. André Vorbach

WSDL. Web Services Description Language. André Vorbach. André Vorbach André Vorbach WSDL Web Services Description Language André Vorbach Übersicht Was ist WSDL? Dokumentenstruktur Elemente Definitions Types Messages porttype Binding Service SOAP-Bindings Beispiel Was ist

Mehr

Bernd Blümel. Verschlüsselung. Prof. Dr. Blümel

Bernd Blümel. Verschlüsselung. Prof. Dr. Blümel Bernd Blümel 2001 Verschlüsselung Gliederung 1. Symetrische Verschlüsselung 2. Asymetrische Verschlüsselung 3. Hybride Verfahren 4. SSL 5. pgp Verschlüsselung 111101111100001110000111000011 1100110 111101111100001110000111000011

Mehr

Technische Universität München. SAML/Shibboleth. Ein Vortrag von Florian Mutter

Technische Universität München. SAML/Shibboleth. Ein Vortrag von Florian Mutter SAML/Shibboleth Ein Vortrag von Florian Mutter Security Assertion Markup Language XML-basierter Standard für den Austausch von Authentifizierungs-, Attributs- Berechtigungsinformationen Seit 2001 von OASIS

Mehr

Bewertung der Einsatzmöglichkeiten von XML Sicherheitslösungen in mobilen Kommunikationsumgebungen. Fabian Pretsch

Bewertung der Einsatzmöglichkeiten von XML Sicherheitslösungen in mobilen Kommunikationsumgebungen. Fabian Pretsch Bewertung der Einsatzmöglichkeiten von XML Sicherheitslösungen in mobilen Kommunikationsumgebungen Fabian Pretsch Ziel Implementierung von XML Encryption/Signature in Java Testen der Implementierung auf

Mehr

XML- und Webservice- Sicherheit

XML- und Webservice- Sicherheit XML- und Webservice- Sicherheit 3. Web Service Security 3.2 WS-Security Erweiterungsstandards Gliederung 1. WSDL 2. WS-Policy 3. WS-SecurityPolicy Literatur: J. Rosenberg and D. Remy, Securing Web Services

Mehr

Secure WebServices (SWS)

Secure WebServices (SWS) Verteilte Datenbanksysteme SS2005 Masterstudiengang Informatik HS-Harz Roadmap 1. Sicherheitsprobleme WebServices 2. a) XML- b) Signature XML- Encryption Anwendung im E-Government Anwendung im E-Commerce

Mehr

Das Secure E-Mail-System der Hamburger Sparkasse

Das Secure E-Mail-System der Hamburger Sparkasse Das Secure E-Mail-System der Hamburger Sparkasse Die Absicherung Ihrer E-Mails von und an die Haspa Kundeninformation und Kurzanleitung Bei Problemen mit Secure E-Mail wenden Sie sich bitte an das Service-Center

Mehr

Verschlüsselte E-Mails: Wie sicher ist sicher?

Verschlüsselte E-Mails: Wie sicher ist sicher? Verschlüsselte E-Mails: Wie sicher ist sicher? Mein Name ist Jörg Reinhardt Linux-Administrator und Support-Mitarbeiter bei der JPBerlin JPBerlin ist ein alteingesessener Provider mit zwei Dutzend Mitarbeitern

Mehr

Stammtisch 04.12.2008. Zertifikate

Stammtisch 04.12.2008. Zertifikate Stammtisch Zertifikate Ein Zertifikat ist eine Zusicherung / Bestätigung / Beglaubigung eines Sachverhalts durch eine Institution in einem definierten formalen Rahmen 1 Zertifikate? 2 Digitale X.509 Zertifikate

Mehr

TLS ALS BEISPIEL FÜR EIN SICHERHEITSPROTOKOLL

TLS ALS BEISPIEL FÜR EIN SICHERHEITSPROTOKOLL 1 TLS ALS BEISPIEL FÜR EIN SICHERHEITSPROTOKOLL Kleine Auswahl bekannter Sicherheitsprotokolle X.509 Zertifikate / PKIX Standardisierte, häufig verwendete Datenstruktur zur Bindung von kryptographischen

Mehr

Secure Sockets Layer (SSL) Prof. Dr. P. Trommler

Secure Sockets Layer (SSL) Prof. Dr. P. Trommler Secure Sockets Layer (SSL) Prof. Dr. P. Trommler Übersicht Internetsicherheit Protokoll Sitzungen Schlüssel und Algorithmen vereinbaren Exportversionen Public Keys Protokollnachrichten 29.10.2003 Prof.

Mehr

Grundlagen der Web-Entwicklung INF3172

Grundlagen der Web-Entwicklung INF3172 Grundlagen der Web-Entwicklung INF3172 Web-Services Thomas Walter 16.01.2014 Version 1.0 aktuelles 2 Webservice weitere grundlegende Architektur im Web: Webservice (Web-Dienst) Zusammenarbeit verschiedener

Mehr

Kundenleitfaden Secure E-Mail

Kundenleitfaden Secure E-Mail Vorwort Wir leben in einem elektronischen Zeitalter. Der Austausch von Informationen erfolgt zunehmend über elektronische Medien wie das Versenden von E-Mails. Neben den großen Vorteilen, die uns elektronische

Mehr

Securing SOAP e-services

Securing SOAP e-services Securing SOAP e-services Nilson Reyes Sommersemester 2004 aus: E. Damiani, S. De Capitani di Vermercati, S. Paraboschi, P. Samarati, Securing SOAP e-sservices, IJIS, Ausgabe 1 (2002), S.110-115. Gliederung

Mehr

Beschreibung und Bedienungsanleitung. Inhaltsverzeichnis: Abbildungsverzeichnis: Werkzeug für verschlüsselte bpks. Dipl.-Ing.

Beschreibung und Bedienungsanleitung. Inhaltsverzeichnis: Abbildungsverzeichnis: Werkzeug für verschlüsselte bpks. Dipl.-Ing. www.egiz.gv.at E-Mail: post@egiz.gv.at Telefon: ++43 (316) 873 5514 Fax: ++43 (316) 873 5520 Inffeldgasse 16a / 8010 Graz / Austria Beschreibung und Bedienungsanleitung Werkzeug für verschlüsselte bpks

Mehr

Symmetrische und Asymmetrische Kryptographie. Technik Seminar 2012

Symmetrische und Asymmetrische Kryptographie. Technik Seminar 2012 Symmetrische und Asymmetrische Kryptographie Technik Seminar 2012 Inhalt Symmetrische Kryptographie Transpositionchiffre Substitutionchiffre Aktuelle Verfahren zur Verschlüsselung Hash-Funktionen Message

Mehr

Mail encryption Gateway

Mail encryption Gateway Mail encryption Gateway Anwenderdokumentation Copyright 06/2015 by arvato IT Support All rights reserved. No part of this document may be reproduced or transmitted in any form or by any means, electronic

Mehr

Digital Signature and Public Key Infrastructure

Digital Signature and Public Key Infrastructure E-Governement-Seminar am Institut für Informatik an der Universität Freiburg (CH) Unter der Leitung von Prof. Dr. Andreas Meier Digital Signature and Public Key Infrastructure Von Düdingen, im Januar 2004

Mehr

Autor: Peter Seemann Seminar: Softwarearchitekturen Betreuer: Benedikt Meurer

Autor: Peter Seemann Seminar: Softwarearchitekturen Betreuer: Benedikt Meurer Autor: Peter Seemann Seminar: Softwarearchitekturen Betreuer: Benedikt Meurer *Was sind Web Services? *Beispiele für Web Services *Web Service Architektur *Web Services Technologien *Fazit 2 *Übertragungsstandard

Mehr

Merkblatt: HSM. Version 1.01. Systemvoraussetzungen, Setup und Trouble Shooting. pdfsupport@pdf-tools.com

Merkblatt: HSM. Version 1.01. Systemvoraussetzungen, Setup und Trouble Shooting. pdfsupport@pdf-tools.com Merkblatt: HSM Version 1.01 Systemvoraussetzungen, Setup und Trouble Shooting Kontakt: pdfsupport@pdf-tools.com Besitzer: PDF Tools AG Kasernenstrasse 1 8184 Bachenbülach Schweiz www.pdf-tools.com Copyright

Mehr

E-Mails versenden aber sicher! Secure E-Mail. Kundenleitfaden. Sparkasse Landshut

E-Mails versenden aber sicher! Secure E-Mail. Kundenleitfaden. Sparkasse Landshut E-Mails versenden aber sicher! Secure E-Mail Kundenleitfaden S Vorwort Wir alle leben in einem elektronischen Zeitalter. Der Austausch von Informationen erfolgt zunehmend über elektronische Medien wie

Mehr

Datenempfang von crossinx

Datenempfang von crossinx Datenempfang von crossinx Datenempfang.doc Seite 1 von 6 Inhaltsverzeichnis 1 Einführung... 3 2 AS2... 3 3 SFTP... 3 4 FTP (via VPN)... 4 5 FTPS... 4 6 Email (ggf. verschlüsselt)... 5 7 Portalzugang über

Mehr

Company. Sicherheit und WebServices CORISECIO CORISECIO. Dr. Bruno Quint CORISECIO. BESEQURE gegründet 2002 in Darmstadt Germany

Company. Sicherheit und WebServices CORISECIO CORISECIO. Dr. Bruno Quint CORISECIO. BESEQURE gegründet 2002 in Darmstadt Germany Corporate Information Security Sicherheit und Webs Dr. Bruno Quint GmbH. Uhlandstr. 9. D-64297 Darmstadt. Germany. www.corisecio.com Company BESEQURE gegründet 2002 in Darmstadt Germany umbenannt 2007

Mehr

Secure Socket Layer V.3.0

Secure Socket Layer V.3.0 Konzepte von Betriebssystem-Komponenten Schwerpunkt Internetsicherheit Secure Socket Layer V.3.0 (SSLv3) Zheng Yao 05.07.2004 1 Überblick 1.Was ist SSL? Bestandteile von SSL-Protokoll, Verbindungherstellung

Mehr

Vorwort. Sichere E-Mail bietet. Kundenleitfaden Sichere E-Mail

Vorwort. Sichere E-Mail bietet. Kundenleitfaden Sichere E-Mail Vorwort Wir alle leben in einem elektronischen Zeitalter. Der Austausch von Informationen erfolgt zunehmend über elektronische Medien wie das Versenden von E-Mails. Neben den großen Vorteilen, die uns

Mehr

SECTINO. Security for Inter-Organizational Workflows

SECTINO. Security for Inter-Organizational Workflows SECTINO Security for Inter-Organizational Workflows Framework zur Modellierung und Realsisierung sicherheitskritischer organisationsübergreifender Workflows Kooperation Research Group Quality Engineering

Mehr

SSL-Protokoll und Internet-Sicherheit

SSL-Protokoll und Internet-Sicherheit SSL-Protokoll und Internet-Sicherheit Christina Bräutigam Universität Dortmund 5. Dezember 2005 Übersicht 1 Einleitung 2 Allgemeines zu SSL 3 Einbindung in TCP/IP 4 SSL 3.0-Sicherheitsschicht über TCP

Mehr

Informationen zur sicheren E-Mail-Kommunikation. Unternehmensgruppe ALDI SÜD

Informationen zur sicheren E-Mail-Kommunikation. Unternehmensgruppe ALDI SÜD Informationen zur sicheren E-Mail-Kommunikation Unternehmensgruppe ALDI SÜD Sichere E-Mail-Kommunikation Vorwort E-Mail ist heute für Unternehmen ein häufig eingesetztes Kommunikationsmittel, das zum Austausch

Mehr

Senden von strukturierten Berichten über das SFTP Häufig gestellte Fragen

Senden von strukturierten Berichten über das SFTP Häufig gestellte Fragen Senden von strukturierten Berichten über das SFTP Häufig gestellte Fragen 1 Allgemeines Was versteht man unter SFTP? Die Abkürzung SFTP steht für SSH File Transfer Protocol oder Secure File Transfer Protocol.

Mehr

Anwenderinnen und Anwender im IT-Verbund des Evangelischen Oberkirchenrats Stuttgart

Anwenderinnen und Anwender im IT-Verbund des Evangelischen Oberkirchenrats Stuttgart Evangelischer Oberkirchenrat Gänsheidestraße 4 70184 Stuttgart Bei Rückfragen wenden Sie sich bitte an folgende Nummer: 0711 2149-533 Anwenderinformation des Referats Informationstechnologie Thema Betroffene

Mehr

Einführung in PGP/GPG Mailverschlüsselung

Einführung in PGP/GPG Mailverschlüsselung Einführung in PGP/GPG Mailverschlüsselung Vorweg bei Unklarheiten gleich fragen Einsteiger bestimmen das Tempo helft wo Ihr könnt, niemand ist perfekt Don't Panic! Wir haben keinen Stress! Diese Präsentation

Mehr

Autorisierung. Sicherheit und Zugriffskontrolle & Erstellen einer Berechtigungskomponente

Autorisierung. Sicherheit und Zugriffskontrolle & Erstellen einer Berechtigungskomponente Autorisierung Sicherheit und Zugriffskontrolle & Erstellen einer Berechtigungskomponente Dokumentation zum Referat von Matthias Warnicke und Joachim Schröder Modul: Komponenten basierte Softwareentwickelung

Mehr

IT-Sicherheit Kapitel 3 Public Key Kryptographie

IT-Sicherheit Kapitel 3 Public Key Kryptographie IT-Sicherheit Kapitel 3 Public Key Kryptographie Dr. Christian Rathgeb Sommersemester 2013 1 Einführung In der symmetrischen Kryptographie verwenden Sender und Empfänger den selben Schlüssel die Teilnehmer

Mehr

SSL Secure Socket Layer Algorithmen und Anwendung

SSL Secure Socket Layer Algorithmen und Anwendung SSL Secure Socket Layer Algorithmen und Anwendung Präsentation vom 03.06.2002 Stefan Pfab 2002 Stefan Pfab 1 Überblick Motivation SSL-Architektur Verbindungsaufbau Zertifikate, Certification Authorities

Mehr

Inhalt Einführung Was ist SAML Wozu braucht man SAML Wo wird SAML verwendet kleine Demo SAML. Security Assertion Markup Language.

Inhalt Einführung Was ist SAML Wozu braucht man SAML Wo wird SAML verwendet kleine Demo SAML. Security Assertion Markup Language. Inhalt Einführung Was ist Wozu braucht man Wo wird verwendet kleine Demo Security Assertion Markup Language Björn Rathjens Inhalt Einführung Was ist Wozu braucht man Wo wird verwendet kleine Demo 1 Einführung

Mehr

E-Mail-Verschlüsselung mit Geschäftspartnern

E-Mail-Verschlüsselung mit Geschäftspartnern E-Mail-Verschlüsselung mit (Anleitung für Geschäftspartner) Datum: 13.07.2011 Dokumentenart: Anwenderbeschreibung Version: 3.0 : Redaktionsteam PKI cio.siemens.com Inhaltsverzeichnis 1. Zweck des Dokumentes:...3

Mehr

E-Mail-Verschlüsselung

E-Mail-Verschlüsselung E-Mail-Verschlüsselung German Privacy Foundation e.v. Schulungsreihe»Digitales Aikido«Workshop am 15.04.2009 Jan-Kaspar Münnich (jan.muennich@dotplex.de) Übertragung von E-Mails Jede E-Mail passiert mindestens

Mehr

Merkblatt: Sichere E-Mail-Kommunikation zur datenschutz cert GmbH

Merkblatt: Sichere E-Mail-Kommunikation zur datenschutz cert GmbH Version 1.3 März 2014 Merkblatt: Sichere E-Mail-Kommunikation zur datenschutz cert GmbH 1. Relevanz der Verschlüsselung E-Mails lassen sich mit geringen Kenntnissen auf dem Weg durch die elektronischen

Mehr

Benutzer- und Datensicherheit. Ralf Abramowitsch Vector Informatik GmbH abramowitsch@lehre.dhbw-stuttgart.de

Benutzer- und Datensicherheit. Ralf Abramowitsch Vector Informatik GmbH abramowitsch@lehre.dhbw-stuttgart.de Benutzer- und Datensicherheit Ralf Abramowitsch Vector Informatik GmbH abramowitsch@lehre.dhbw-stuttgart.de Authentifizierung vs. Autorisierung IIdentity vs. IPrincipal Verschlüsseln und Entschlüsseln

Mehr

ESecuremail Die einfache Email verschlüsselung

ESecuremail Die einfache Email verschlüsselung Wie Sie derzeit den Medien entnehmen können, erfassen und speichern die Geheimdienste aller Länder Emails ab, egal ob Sie verdächtig sind oder nicht. Die Inhalte von EMails werden dabei an Knotenpunkten

Mehr

Beuth Hochschule BEUTH HOCHSCHULE FÜR TECHNIK BERLIN University of Applied Sciences

Beuth Hochschule BEUTH HOCHSCHULE FÜR TECHNIK BERLIN University of Applied Sciences Beuth Hochschule BEUTH HOCHSCHULE FÜR TECHNIK BERLIN University of Applied Sciences WISSENSCHAFTLICHE WEITERBILDUNG Fernstudium Industrial Engineering Produktions- und Betriebstechnik Kurseinheit 98 und

Mehr

IT-Sicherheit WS 2012/13. Übung 5. zum 28. November 2012

IT-Sicherheit WS 2012/13. Übung 5. zum 28. November 2012 Prof. Dr. C. Eckert Thomas Kittel IT-Sicherheit WS 2012/13 Übung 5 zum 28. November 2012 Institut für Informatik Lehrstuhl für Sicherheit in der Informatik 1 X.509-Zertifikate Zertifikate nach dem X.509-Standard

Mehr

Microsoft Outlook Express 5.x (S/MIME-Standard)

Microsoft Outlook Express 5.x (S/MIME-Standard) Microsoft Outlook Express 5.x (S/MIME-Standard) Das E-Mail-Programm Outlook Express von Microsoft bietet Ihnen durch die Standard- Integration des E-Mail-Verschlüsselungsprotokolls S/MIME (Secure/MIME)

Mehr