Webservice Sicherheit

Größe: px
Ab Seite anzeigen:

Download "Webservice Sicherheit"

Transkript

1 Webservice Sicherheit XML-basiert, WS-* und SAML Semesterbegleitende Prüfungsleistung im Fach: IT- Sicherheit an der Fachhochschule Dortmund im Fachbereich 04 im Studiengang Informatik Autor: Andreas Beckers Matrikel-Nr: Erstprüfer: Prof. Dr. Eren Datum: 27. Januar 2011

2 Inhalt II Inhalt Inhalt... II 1 Einleitung Webservice Definition / Begriffserklärung Motivation Zielsetzung Abgrenzung XML-bezogene Absicherung XML-Encryption Einschränkungen XML-Signature Implementierung Einschränkungen WS-* Standards zur Webservice Absicherung WS-Security WS-SecureConversation WS-Policy Security Assertion Markup Language (SAML) Umsetzungsmöglichkeiten Project Metro (JAX-WS Reference Implementation) Apache Axis2 mit Rampart Apache CXF Fazit Abbildungsverzeichnis Codeausschnittverzeichnis Tabellenverzeichnis Literaturverzeichnis... 22

3 1 Einleitung 1 1 Einleitung 1.1 Webservice Definition / Begriffserklärung Bei Webservices handelt es sich um modulare Softwarekomponenten, die über das Internet lokalisiert und aufgerufen werden. Sie kapseln die Funktionalität einer Anwendung und stellen diese standardisiert über das Internet zur Verfügung. Die gekapselten Module können dynamisch integriert und zu komplexen Prozess- und Geschäftsabläufen zusammengefügt werden. Ein Webservice selbst ist aber keine eigenständige Applikation, sondern bildet die Schnittstelle zwischen dem Web und der tatsächlichen Anwendungslogik des zur Verfügung gestellten Dienstes. Da es sich bei Webservices im Prinzip um dynamische Web-Ressourcen handelt, nutzen sie die vorhandene Internet- und Web-Infrastruktur und stellen keine weiteren technischen Anforderungen. 1.2 Motivation Webservices sind ein gängiger Standard zur Kommunikation und zum Datenaustausch zwischen Unternehmensanwendungen geworden. Komplizierte und mächtige Technologien wie CORBA (Common Object Request Broker Architecture) haben längst ausgedient. Die Vorteile der im Vergleich einfachen Implementierung und der problemlosen Datenübertragung innerhalb von Unternehmensnetzen überwiegen. Demnach sind keine speziellen Firewallregeln anzupassen, da über das Web-Protokoll HTTP kommuniziert wird. Das wiederum sollte einen Entwickler sensibilisieren, bei der Implementierung auch auf Sicherheit der Services zu achten. Es existieren zahlreiche Angriffsmöglichkeiten, wie sie in [Radh07, S. 171 ff] beschrieben wurden. Das sind zum Beispiel: WSDL-Scanning und Parameter Tampering Dabei beschafft sich der Angreifer die offen liegende WSDL-Datei und informiert sich über freigegebene Methoden und deren Parameter. Anschließend sendet er verschiedene, manipulierte SOAP-Nachrichten an den Dienstanbieter um Schwächen in der Implementierung ausfindig zu machen, die er schließlich ausnutzen kann, um dem Anbieter zu Schaden oder eigenen Nutzen davon ziehen zu können. SQL-Injection Durch die oben beschriebene Möglichkeit lässt sich auch eine SQL-Injection Attacke durchführen, in dem in den Parametern der Services entsprechender SQL-Code eingefügt wird, um so zum Beispiel einen Authentifizierungsprozess zu manipulieren. Routing-Detours Ein Angreifer hat ebenfalls die Möglichkeit, die durch das Internet gerouteten SOAP- Nachrichten durch einen manipulierten Router nach dem Man-In-The-Middle Prinzip abzufangen. Er kann anschließlich unternehmenskritische Informationen aus diesen Nachrichten abziehen und sie einfach weiterleiten, als ob nichts geschehen wäre.

4 1 Einleitung 2 Malicious Contents Diese Attacke bezieht sich auf das Hinzufügen/Ändern von ausführbaren Dateien in den SOAP-Nachrichten. Angreifer können so initieren, das schadhafter Code wie Trojaner, Würmer und Viren im schließlich kompromittierten System in Gange kommen. Diese Beispiele und viele weitere Möglichkeiten sind die Motivation für diese Arbeit. Webservices sollten, vor allem wenn Sie das unternehmerische Netz verlassen, abgesichert werden. 1.3 Zielsetzung Es existieren zahlreiche Möglichkeiten, Webservices auf verschiedenen Leveln abzusichern. Zum einen kann auf niedrigem Level die Transportschicht abgesichert werden. Dazu käme zum Beispiel SSL (Secure Socket Layer) in Frage. Auf etwas höherem Level könnte man die reinen Nachrichten, die üblicherweise im XML- Format abgebildet sind, absichern. Etwas tiefer in der Webservice Struktur, kann außerdem nach diversen Webservice Standards, nämlich WS-*, abgesichert werden. Dazu kommen dann noch sogenannte High-Level Frameworks, die auf höherer Ebene erweiterte Sicherheit anbieten. Die folgende Abbildung soll diesen Zusammenhang noch mal veranschaulichen. High-Level Framework Z.B. SAML XML WS-* SOAP XML-Encyrption XML-Signature Non- XML Transport-Layer Security z.b. SSL Transport Layer: HTTP TCP/IP Abbildung 1: XML- und Webservice Sicherheit In dieser Arbeit wird die Sicherheit der XML-Ebene angesprochen. Dazu werden zuerst die allgemeineren Methoden XML-Encryption und XML-Signature erörtert. Anschließend wird auf die SOAP-basierte Sicherheit mittel der WS-* Standards WS-Security, WS-SecureConversation und WS-Policy eingegangen. Zum Abschluss wird noch das Framework SAML vorgestellt, das auf höherer Ebene zur Authentifizierung und Autorisierung zuständig ist. Zum Schluss wird noch ein Überblick über einige Frameworks gegeben, die die oben genannten Sicherheitsaspekte umgesetzt haben und dem Entwickler ermöglichen, gesicherte Webservices zu implementieren.

5 1 Einleitung Abgrenzung In dieser Arbeit wird überwiegend auf die Absicherung von SOAP-Webservices eingegangen. Alle WS-* Standards der OASIS Organisation beziehen sich auf diese und spielen für zum Beispiel REST-Services keine Rolle. Sicherlich können die XML-basierten Absicherungen bei REST eingesetzt werden, werden hier aber nur als Grundlage für die weiteren Techniken dargestellt. Aber warum wird in dieser Arbeit nicht auch REST-Sicherheit angesprochen, obwohl diese Technologie doch immer mehr an Bedeutung gewinnt? Das ist daher begründet, dass REST- Sicherheit in dem Kontext dieser Arbeit gar nicht existiert (vgl. [Come10]). Es existieren keine standardisierten Mechanismen und deshalb müssen Entwickler selbst tricksen. Da sich REST nichts anderes als HTTP ist, kann dort zum Beispiel SSL zum Einsatz kommen. Diese Arbeit befasst sich aber nicht mit solchen Tricks und ist auf standardisierte Absicherung von Webservices fokussiert.

6 2 XML-bezogene Absicherung 4 2 XML-bezogene Absicherung 2.1 XML-Encryption Die XML-Encryption Syntax- and Processing Spezifikation beschreibt Regeln, wie Daten ver- und entschlüsselt werden. Diese Spezifikation beschreibt außerdem die Syntax, wie verschlüsselte Daten im XML-Format repräsentiert werden sollen. Unterstützt werden unter anderem das komplette Verschlüsseln des Dokuments sowie einzelne XML-Elemente und deren Inhalte. Als Beispiel sei folgendes, unverschlüsseltes XML-Dokument in Codeausschnitt 1. <?xml version='1.0'?> <PaymentInfo xmlns='http://example.org/paymentv2'> <Name>John Smith</Name> <CreditCard Limit='5,000' Currency='USD'> <Number> </Number> <Issuer>Example Bank</Issuer> <Expiration>04/02</Expiration> </CreditCard> </PaymentInfo> Codeausschnitt 1: XML-Dokument vor XML-Encryption Dieser Nachricht können alle wichtigen Informationen des Kunden wie zum Beispiel die Kreditkartennummer als Klartext entnommen werden. Nach einer XML- Encryption würde sich die Nachricht wie folgt verändern. <?xml version='1.0'?> <PaymentInfo xmlns='http://example.org/paymentv2'> <Name>John Smith</Name> <EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#' Type='http://www.w3.org/2001/04/xmlenc#Element'/> <EncryptionMethod Algorithm= 'http://www.w3.org/2001/04/xmlenc#tripledes-cbc'/> <ds:keyinfo xmlns:ds='http://www.w3.org/2000/09/xmldsig#'> <ds:keyname>john Smith</ds:KeyName> </ds:keyinfo> <CipherData><CipherValue>DEADBEEF</CipherValue></CipherData> </EncryptedData> </PaymentInfo> Codeausschnitt 2: XML-Dokument nach XML-Encryption Es kommen einige Elemente hinzu, die zum einen erkenntlich machen, dass verschlüsselter Code folgt und zum anderen die eigentliche Verschlüsselungsmethode sowie Informationen zum verwendeten Schlüssel. Im Element CipherData werden dann (hier verkürzt dargestellt) die verschlüsselten Daten abgelegt.

7 2 XML-bezogene Absicherung Einschränkungen XML-Enryption ist sehr flexibel und erlaubt es, viele Parameter durch das CipherData-Element zu verbergen. Üblicherweise ist Flexibilität eine gute Eigenschaft. Da es aber keine genauen Richtlinien gibt, kann es zu Problemen bei der Entschlüsselung auf der anderen Seite kommen. Des Weiteren gibt XML-Encryption keine Vorgaben, wie etwas genau verschlüsselt werden soll. Der Nutzer muss sich selbst darum kümmern, welche Algorithmen eingesetzt werden und dass die Schlüssellängen lang genug gewählt werden. Eine weitere Einschränkung ist die Nutzung von XML-Encryption bei SOAPbasierten XML-Nachrichten, wie sie bei Webservices vorkommen. Die Spezifikation beschreibt nämlich nicht genau, wie genau eine SOAP-Nachricht mit dieser Methode behandelt werden soll [Hart03, S. 87]. 2.2 XML-Signature Die XML-Signature Standardisierung (W3C 2002j) beschreibt, wie digitale Daten signiert werden können und wie das Resultat in XML repräsentiert werden soll. Prinzipiell können, wie auch bei der XML-Encryption, einzelne Segmente signiert werden, aber auch die ganze XML-Nachricht. Diese Standardisierung der W3C beruht auf existierende Algorithmen für die Signatur, den Message Digest sowie den Message Authentication Code. Des Weiteren bietet es die Unterstützung von Zertifikaten, wie zum Beispiel X.509. Digitale Signaturen auf XML-Ebene sind weitaus komplexer zu implementieren, als XML-Encryption. Der Grund ist, dass Signaturen an die Repräsentation der Daten gebunden sind. Es muss also darauf geachtet werden, dass die signierten Daten mit den verifizierten Daten konsistent gehalten werden. Probleme treten auf, wenn während des Routing der Nachrichten diese auch nur minimal verändert werden. Denn dann kann es passieren, dass die Nachricht nicht mehr valide ist. Grundsätzlich kommen bei XML-Signature die Elemente SignedInfo, SignatureValue und KeyInfo hinzu, die folglich kurz erläutert werden: SignedInfo In diesem Element werden die Methoden und Algorithmen, sowie deren Parameter beschrieben, die eingesetzt werden, um die Signatur zu erzeugen. Üblicherweise sind das Digest- und Signature-Algorithmen. Zum Beispiel könnte dort der SHA-1 Algorithmus definiert werden. Das Teilelement der XML-Nachricht sieht so aus, wie es in Codeausschnitt 3 dargestellt ist. <SignedInfo> <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n "/> <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> <Reference URI=""> <Transforms> <Transform Algorithm="http://www.w3.org/2000/09/xmldsig# enveloped-signature"/> </Transforms> <DigestMethod

8 2 XML-bezogene Absicherung 6 Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <DigestValue>tVicGh6V+8cHbVYFIU91o5+L3OQ=</DigestValue> </Reference> </SignedInfo> Codeausschnitt 3: XML-Signature Element: SignedInfo Beispiel Des Weiteren ist dort eine Referenz auf die Daten enthalten, die signiert wurden. SignatureValue Wie der Name schon vermuten lässt, ist der Inhalt dieses Elements der tatsächliche Wert der Signatur base64-codiert. KeyInfo In diesem Element sind Informationen enthalten, die der Empfänger benötigt, um die Signatur zu überprüfen. Wenn dieses Element leer gelassen wird, wird angenommen, dass die Partner bereits alle nötigen Informationen ausgetauscht haben. Ansonsten können hier Key Identifier, der Public Key des Signierers, eine Referenz, wo der Public Key zu finden ist, oder ähnlich Dinge angegeben werden. In Codeausschnitt 4 ist ein Beispiel KeyInfo-Element mit einem X.509 Zertifikat angegeben [Hart03, S. 88 ff]. <KeyInfo> <X509Data> <X509SubjectName> CN=My Name,O=Test Certificates Inc.,C=US </X509SubjectName> <X509Certificate> MIIB9zCCAWCgAwIBAgIERZwdkzANBgkqhkiG9w0BAQUFADBAMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWVGVzdCBDZXJ0aWZpY2F0ZXMgSW5jLjEQ MA4GA1UEAxMHTXkgTmFtZTAeFw0wNzAxMDMyMTE4MTFaFw0zMTA4MjUy... </X509Certificate> </X509Data> </KeyInfo> Codeausschnitt 4: XML-Signature Element KeyInfo Beispiel Implementierung Zur Implementierung von XML-Signature kann das Java XML Digital Signature API herangezogen werden. Dieses bietet bereits einige Methoden, die das Signieren von XML-Nachrichten vereinfachen. In wird gezeigt, wie der komplette signature- Umschlag mit den im vorherigen Kapitel beschriebenen Elementen erzeugt werden kann. XMLSignatureFactory fac = XMLSignatureFactory.getInstance("DOM"); DigestMethod digestmethod = fac.newdigestmethod( "http://www.w3.org/2000/09/xmldsig#sha1", null); Reference ref = fac.newreference("#10",digestmethod); ArrayList reflist = new ArrayList(); reflist.add(ref); CanonicalizationMethod cm = fac.newcanonicalizationmethod( "http://www.w3.org/2001/10/xml-exc-c14n#",null); SignatureMethod sm = fac.newsignaturemethod( "http://www.w3.org/2000/09/xmldsig#rsa-sha1",null); SignedInfo signedinfo =fac.newsignedinfo(cm,sm,reflist); DOMSignContext signcontext = null; signcontext = new DOMSignContext(privKey,securityHeader);

9 2 XML-bezogene Absicherung 7 signcontext.seturidereferencer(new URIResolverImpl()); KeyInfoFactory keyfactory = KeyInfoFactory.getInstance(); DOMStructure domkeyinfo = new DOMStructure(tokenReference); KeyInfo keyinfo = keyfactory.newkeyinfo( Collections.singletonList(domKeyInfo)); XMLSignature signature = fac.newxmlsignature(signedinfo,keyinfo); signature.sign(signcontext); Codeausschnitt 5: Implementierung zum Generieren einer XML-Signatur Zuerst wird eine Instanz der XMLSignatureFactory erzeugt und daraus wiederum eine Referenz Reference, die die eigentlichen Zielelemente definiert. Dazu wird zum einen das Ziel als xpointer angegeben und zum anderen die Digest-Methode, die zuvor als Objekt erzeugt wurde. Anschließend werden weitere Informationen generiert, wie zum Beispiel die zuvor genannten Elemente KeyInfo und SignedInfo. Der eigentliche Wert der Signatur im Element SignatureValue wird schließlich durch Aufruf der Methode sign() erzeugt. Zum Validieren bietet dieses Framework ebenfalls einige Hilfsmethoden und wird zur Vollständigkeit in Codeausschnitt 6 dargestellt. public boolean validate(element signature){ DOMValidateContext validationcontext = new DOMValidateContext(new KeySelectorImpl(), signature); XMLSignatureFactory signaturefactory = XMLSignatureFactory.getInstance("DOM"); XMLSignature signature = signaturefactory.unmarshalxmlsignature(validationcontext); validationcontext.seturidereferencer(new URIResolverImpl()); boolean validmessage = signature.validate(validationcontext); if(validmessage){ System.out.println("Signature Validation passed"); } else { System.out.println("Signature Validation Failed"); } return validmessage; } Codeausschnitt 6: Validierung einer signierten XML-Nachricht Dieser Validierungsmethode wird der komplette Signaturumschlag der XML- Nachricht übergeben, die dort schließlich überprüft wird. Dazu wird ein Dom- Validationskontext generiert, der die DOM-Repräsentation sowie eine neue Implementierung eines KeySelector als Parameter übergeben bekommt. Letzterer wird benötigt, um an den Key zu gelangen, der zur eigentlich Validierung benötigt wird. Ein Objekt von XMLSignature wird erzeugt, der die eigentliche Signatur repräsentiert. Dazu wird ein sogenanntes Unmarshalling der XML-Nachricht durchgeführt. Zu guter Letzt, bevor die Validierung durchgeführt werden kann, müssen noch die eigentlichen Referenzen bekannt gegeben werden, was in der XML-Nachricht signiert wurde. Dies geschieht über den URIDereferencer. Durch die Methode validate() findet schließlich die Validierung statt [Orac06] Einschränkungen Wie in der Implementierung zu sehen ist, werden die einzelnen XML-Nachrichten feingranular behandelt, signiert und validiert. Das erfordert vom Entwickler ein tiefes Eindringen in Schicht der Nachrichtenübermittlung. Das heißt im Webservice Kontext genau, dass einzelne empfangene oder zu versendende Pakete

10 2 XML-bezogene Absicherung 8 abgefangen und weiterverarbeitet werden müssen. Das gibt einem Entwickler zwar die volle Kontrolle, jedoch ist der Implementierungsaufwand sehr hoch. Deshalb werden im nächsten Kapitel die WS-* Standards zur Absicherung von Webservices erläutert, die schon in diversen Webservice Frameworks integriert sind und ohne großen Aufwand aktiviert werden können. Darin wird dann auf komfortableren Weg auf die beiden XML-Absicherungen zurückgegriffen.

11 3 WS-* Standards zur Webservice Absicherung 9 3 WS-* Standards zur Webservice Absicherung Bei WS-* handelt es sich um eine Sammlung von Spezifikationen im Kontext von Webservices mit SOAP und WSDL. Im Rahmen der WS-* Spezifikationen wurden eine Reihe von Standards definiert, die sich jeweils an ein konkretes Anwendungsgebiet wenden, das in SOAP und WSDL nicht festgelegt wurde, aber für sich genommen trotzdem eine Existenzberechtigung besitzt. Im Folgenden werden die zur Absicherung von Webservices nützlichen Spezifikationen erläutert. Die Namen der Standards werden im Text kursiv dargestellt. 3.1 WS-Security WS-Security kann als de-facto Standard zur Absicherung von SOAP-Nachrichten angesehen werden. Die Arbeit an diesem Standard wurde erstmals im Jahr 2001 begonnen. Im Jahre 2002 wurde WS-Security schließlich als OASIS Standard angenommen. WS-Security spezifiziert Erweiterungen von SOAP die es erlauben, Teile der Nachricht zu signieren und zu verschlüsseln. Dabei wird auf die zuvor beschriebenen Standards XML-Encryption, zur Wahrung der Vertraulichkeit der Nachrichten, und XML-Signature, zur Wahrung der Integrität der Nachrichten, zurückgegriffen. WS-Security unterstützt mehrere Security Token Formate, mehrere Vertrauens Domänen und diverse Verschlüsselungs-Algorithmen. Ein Security Token repräsentiert eine Sammlung an Deklarationen (auch Claim genannt) eines Objekts über einige seiner Eigenschaften, welche aus sicherheitstechnischen Aspekten relevant sind. Das könnte zum Beispiel der Name sein, eine Identität, ein Schlüssel, ein Privileg oder eine Befähigung. Diese sicherheitsrelevanten Informationen können zum Beispiel als X.509 Zertifikat, Kerberos Ticket und Authenticator oder SAML Assertion (siehe Kapitel 4) verpackt und versendet werden. SOAP wird durch WS-Security um ein ws security element (wsse) erweitert, welches die sicherheitsrelevanten Informationen enthält. Dies wird in Abbildung 2 veranschaulicht.

12 3 WS-* Standards zur Webservice Absicherung 10 Abbildung 2: WS.Security: wsse Element Layout Erkennbar hier ist die Anlehnung an das XML-Signature Verfahren, da die Elemente SignedInfo, SignatureValue und KeyInfo übernommen wurden. WS-Security gewährleistet die Vertraulichkeit der Nachrichten indem Teile der SOAP-Nachricht, in Anlehnung an XML-Encryption, mit Hilfe des Security Token, verschlüsselt werden. Der Verschlüsselungsmechanismus ist dabei so entworfen worden, dass mehrere Algorithmen unterstützt werden und auch bei Versand an verschiedene Parteien jeweils unterschiedliche Methoden eingesetzt werden können. [Bert10, S. 56 ff] Generell wird eine solche Sicherheitsmaßnahme in der WSDL-Datei, die die Servcies beschreibt, kenntlich gemacht. Meist wird eine ganze Police aufgebaut, die alle sicherheitstechnischen Funktionen enthält. Dazu dient der weitere Standard WS-Policy, auf den noch später eingegangen wird. 3.2 WS-SecureConversation Während WS-Security lediglich die Sicherung einzelner Nachrichten adressiert, ist es häufig sinnvoll einen Sicherheitskontext zwischen den beteiligten Kommunikationspartnern zu etablieren, wenn mehrere Nachrichten ausgetauscht werden sollen. Dieser Sicherheitskontext wird dann zwischen allen Kommunikationspartnern für die gesamte Länge der Kommunikationen geteilt. Das Konzept impliziert ein gemeinsames Geheimnis.

13 3 WS-* Standards zur Webservice Absicherung 11 WS-SecureConversation baut auf WS-Security auf und erweitert es um ein neues Security Token (SecurityContextToken), welches einen solchen Sicherheitskontext repräsentiert. Nachdem der Sicherheitskontext etabliert wurde und ein gemeinsames Geheimnis unter dem Kommunikationspartner besteht, können alle für die Kommunikation benötigten Schlüssel aus dem Kontext abgeleitet werden. WS-SecureConversation spezifiziert hierzu einen entsprechenden Mechanismus: Einer der Kommunikationspartner erzeugt das Token für den Sicherheitskontext und verteilt es mit Hilfe einer speziellen Nachricht. Die Kommunikationspartner erstellen das Token gemeinsam durch Verhandlung und den Austausch einer speziellen Nachrichtensequenz (vgl. SSL) Ein spezieller Security Token Service (STS, siehe Abbildung 3) ist für die Erstellung der Tokens verantwortlich. Der Initiator des Sicherheitskontextes fordert dieses beim STS an (2) und es wird anschließend durch einen speziellen Mechanismus (3) an alle Kommunikationspartner verteilt. Abbildung 3: WS-SecureConversation: Sicherheitskontext für WS-Security Jede der drei Optionen erfordert einen besonderen Mechanismus zur Anforderung, Übermittlung oder Verteilung des gemeinsamen Kontextes. Ein solcher wird von einer weiteren Spezifikation namens WS-Trust definiert. Sowohl WS- SecureConversation als auch WS-Trust liegen OASIS zur Standardisierung vor. [Frot07, S. 533 f] 3.3 WS-Policy Der WS-Policy Standard bietet ein erweiterbares Modell und eine einzige Grammatik an, damit Webservices eigene Policen aufstellen und beschreiben können. Der Kern dieses Modells ist das Konzept der Policy Assertion, welches das Verhalten, die Voraussetzungen und das Leistungsvermögen einer Police beschreibt. Policy Assertions können aus öffentlichen Spezifikationen wie WS- SecurityPolicy und WS-PolicyAssertion abgeleitet werden, oder aber auch selbst definiert werden. Ersteres wird auch Standard Assertion genannt und kann von jedem Client verstanden werden. Um Policen interoperabel gestalten zu können, wird ein definiertes Schema, also ein bestimmter Aufbau in der WSDL-Datei, vorgegeben. Dieses ist exemplarisch in Codeausschnitt 7 dargestellt.

14 3 WS-* Standards zur Webservice Absicherung 12 <wsp:policy... > <wsp:exactlyone> [<wsp:all> [<Assertion...>... </Assertion> ]* </wsp:all> ]* </wsp:exactlyone> </wsp:policy> Codeausschnitt 7: Definiertes Schema einer Police bei WS-Policy Die eckigen Klammern [ ] kennzeichnen, dass Elemente innerhalb immer als Gruppe auftreten müssen. Der Stern * an einer Gruppe bedeutet, dass diese gar nicht oder beliebig oft auftreten kann. Als Beispiel folgt in Codeausschnitt 8 eine Police nach WS-Policy Spezifikation, die zwei alternative Policen bereitstellt, jede davon als einzelne Policy Assertion. <wsp:policy wsu:id="mypolicy"> <wsp:exactlyone> <wsp:all> <wsse:securitytoken> <wsse:tokentype>wsse:kerberosv5tgt</wsse:tokentype> </wsse:securitytoken> </wsp:all> <wsp:all> <wsse:securitytoken> <wsse:tokentype>wsse:x509v3</wsse:tokentype> </wsse:securitytoken> <wsse:algorithmsuite> <wsp:policy> <wsse:tripledesrsa15 /> </wsp:policy> </wsse:algorithmsuite> </wsp:all> </wsp:exactlyone> </wsp:policy> Codeausschnitt 8: Ein Beispiel einer WS-Policy Police Die Police wird folgendermaßen interpretiert: Wenn die erste Möglichkeit gewählt wird, wird lediglich ein Kerberos Token akzeptiert. Wird hingegen die zweite Möglichkeit gewählt, werden nur X.509 Token akzeptiert aber gleichzeitig eine 3DES Verschlüsselung der Daten hinzugefügt. Im Binding Zweig der WSDL-Datei, wo auch die eigentlichen Operationen definiert werden, kann schließlich folgendermaßen die Police einer beispielhaften addnumbers()-funktion zugewiesen werden (siehe Codeausschnitt 9). <binding name="addnumbersbinding" type="tns:addnumbersporttype"> <wsp:policyreference URI="#MyPolicy"/> <soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document" /> <operation name="addnumbers"> Codeausschnitt 9: Deklarieren einer Police auf einen bestimmten Webservice WS-Policy bietet keine explizite Möglichkeit an, um bestimmte Regeln zu definieren, die ein Service-Anbieter befolgen muss, um eine Police eines Konsumenten gegen die eigene Police zu überprüfen. Viel mehr definiert WS-Policy die Bedingungen, unter denen ein Service-Konsument die Police unterstützt. Das sind nämlich genau folgende drei Möglichkeiten: Eine Policy Assertion wird von einem Konsumenten nur dann unterstützt, wenn er den Anforderungen bezüglich der Assertion gerecht wird

15 3 WS-* Standards zur Webservice Absicherung 13 Eine alternative Police wird von einem Konsumenten nur dann unterstützt, wenn er alle Assertions der Alternative unterstützt Eine Police wird von einem Konsumenten nur dann unterstützt, wenn er mindestens eine der Alternativen unterstützt WS-Policy wird durch drei weitere Standards unterstützt. Das erste, WS- PolicyAssertion, spezifiziert die Struktur einiger Policy Assertions. Das zweite, WS- PolicyAttachment, definiert, wie eine Policy mit einem Webservice assoziiert wird. Entweder durch das direkte Hinzufügen von Statements in die WSDL-Datei, oder durch indirekte Assoziation durch die Registrierung (UDDI). Der Client kann so über öffentlichem Wege Zugriff auf die Policen bekommen, wenn er auf der Suche nach potentiellen Webservices ist. WS-PolicyAttachment beschreibt außerdem, wie implementationsspezifische Policen mit einer WSDL-Datei verknüpft werden können. Der dritte, unterstützende Standard für WS-Policy ist WS-SecurityPolicy. Dieser Standard spezifiziert einen Satz an Standard Policy Assertions die sich dem Schutz und der Sicherheit der SOAP-Nachrichten widmet. Darunter fallen Assertions zur Integrität und Vertraulichkeit der Nachrichten sowie Security Token Assertions. Eine WS-SecurityPolicy Police, die ein Client beim Ergründen von Webservices ausfindig macht, sagt ihm, ob WS-Security zum Nutzen des Services optional oder zwingend erforderlich ist (Siehe Abbildung 4). Abbildung 4: WS-SecurityPolicy Policen Austausch Wenn es erforderlich ist, können Clients so herausfinden, welche Art von Security Token unterstützt oder bevorzugt werden, ob die Nachricht signiert werden soll und wenn ja ob die ganze Nachricht oder nur Teile der Nachricht signiert werden müssen. Außerdem erfährt er, ob die Nachricht verschlüsselt werden muss, und wenn ja, welcher Algorithmus eingesetzt werden muss [Bert10, S. 65 ff].

16 4 Security Assertion Markup Language (SAML) 14 4 Security Assertion Markup Language (SAML) SAML ist eine auf XML basierende Beschreibungssprache, mit der Webservices auf einfache Art und Weise authentifizierungs- und autorisierungsbezogene Informationen austauschen können. SAML liefert einen standardisierten Weg für die Beschreibung von existierenden Sicherheits-Modellen, ermöglicht den Austausch sicherheitsrelevanter Informationen zur Authentifizierung und Autorisierung und basiert darüber hinaus auf Standards und ist plattform- und herstellerunabhängig. Bei SAML wird also die Struktur des Austauschs von Sicherheitsinformationen festgelegt, nicht aber die konkreten Mechanismen. Die drei Hauptbestandteile der SAML-Spezifikation sind: Assertions Hier werden Informationen zu Authentifizierung, Autorisierung sowie weitere Session-Attribute hinterlegt. Protokoll Hier wird definiert, wie SAML-Assertions angefordert und übermittelt werden. Bindings und Profile Hier wird festgelegt, wie SAML-Assertions in Standard-Transport- und Messaging- Frameworks eingebunden werden. SAML-Assertions können digital signiert werden. Assertions werden von so genannten Autoritäten ausgegeben, die zur Veröffentlichung von Bestätigungen bevollmächtigt sind (Assertion Issuing Authorities). In der Praxis können alle drei Arten von Assertions von einer Autorität erzeugt werden. Sämtliche SAML Assertions beinhalten die folgenden allgemeinen Informationen: Die ID des Ausstellers und das Ausgabedatum Die Assertion-ID Ein Subjekt wie zum Beispiel ein öffentlicher Schlüssel Bedingungen, unter denen eine Assertion gültig ist Angaben, wie die Assertion erstellt wurde Das SAML-Protokoll definiert die Interaktion zwischen einem SAML-Requester und einem SAML-Responder. Der Request wird von einem Client gestartet, die Response erfolgt von einem Sicherheitsdienst. Ein SAML-Request kann Queries für Authentifizierung, Attribute und Zugriffsentscheidungen beinhalten. All diese SAML- Requests werden von einem SAML-Response erwidert, der ein oder mehrere Assertions umfasst. Die SAML-Bindings legen fest, wie SAML-Request-Response-Nachrichten über Standard-Übertragungsprotokolle abgebildet werden. SAML definiert ein SOAPover-HTTP-Binding, wobei SOAP hier eingesetzt wird, um eine Anfrage an eine SAML Authority zu stellen und eine entsprechende Antwort zu erhalten. Das SAML- Profil letztendlich spezifiziert, wie Assertions in ein Framework oder Protokoll eingebunden und wieder extrahiert wird. Es existiert zum Beispiel ein WS-Security Profil, das auch Teil der WS-Security Spezifikation ist.

17 4 Security Assertion Markup Language (SAML) 15 SAML dient nicht nur der Absicherung von Webservices. SAML kann außerdem für ein Web Browser Single Sign On (SSO) eingesetzt werden. Dementsprechend muss das SAML-Binding und -Profil für diesen Zweck geändert werden. Diese Art der SAML-Konzeption ist aber außerhalb des Scopes dieser Arbeit. [OASIS05]

18 5 Umsetzungsmöglichkeiten 16 5 Umsetzungsmöglichkeiten Es existieren diverse Frameworks, die es erlauben, Webservices anzubieten oder darauf zuzugreifen, die gleichzeitig einige der WS-* Standards implementiert haben. Die folgende Tabelle soll eine Übersicht der Frameworks und der unterstützten, in den vorherigen Kapiteln beschriebenen, Standards geben. Axis 1.x Axis 2 CXF Glue JBossWS XFire Metro OracleAS 10g XML-Encryption x x x x x x x x XML-Signature x x x x x x x x WS-Security x x x x x x x x WS-Trust x x x WS-SecureConversation x x x WS-Policy x x x WS-SecurityPolicy x x x SAML x x x x x Tabelle 1: WS-* Kompatibilität bei diversen Frameworks [Apa10] Demnach unterstützen die beiden Frameworks Axis2 und CXF von Apache und die JAX-WS Referenz Implementierung Metro Webservices mit allen sicherheitstechnisch relevanten Standards. Folglich werden diese noch kurz vorgestellt, aber nicht näher auf deren Implementierung eingegangen, da diese doch stark von der Architektur und der anwendungsspezifischen Zielsetzung abhängig ist. Eines haben sie aber gemein, da der ganze Sicherheitsstack auf Standards beruht, werden die meisten Sicherheits-Einstellungen in der interoperablen WSDL-Datei getätigt, wie es hier auch schon an einigen Beispielen demonstriert wurde. 5.1 Project Metro (JAX-WS Reference Implementation) Metro ist ein Open Source Webservice Stack des GlassFish Projekts, kann aber auch auf anderen Applikationsserver als dem GlassFish selbst in Betrieb genommen werden. Dieses Projekt ist in der Java Standard Edition (Java SE) ab der Version 6 enthalten und erlaubt es, auf Webservices zuzugreifen. Ein Vorteil dieses Frameworks neben der Unterstützung der wichtigsten Sicherheits- Standards ist die ausführliche Dokumentation. Es existieren zahlreiche Tutorials und Beispiele. Besonders einfach gelingt der Einstieg mit der Entwicklungsumgebung Netbeans und den Tutorials des Enterprise Pakets. Aber auch mit der weit verbreiteten IDE eclipse lassen sich Services implementieren. 5.2 Apache Axis2 mit Rampart

19 5 Umsetzungsmöglichkeiten 17 Apache Axis2 ist ebenfalls eine Kerntechnologie zur Umsetzung von Webservices. Es handelt sich um eine vollständige Neuentwicklung der weit verbreiteten ersten Version des Apache Axis Projekts. Die Stärke dieses Frameworks ist das eigens entwickelte Objektmodell AXIOM, das wesentlich speichereffizienter ist, als zum Beispiel das Document Object Model (DOM). Des Weiteren kann mit Axis2 aus verschiedenen Data Binding Frameworks gewählt werden, die, je nach Bedarf, eine größere Konfigurationsmöglichkeit bieten (XMLBeans) oder benutzerfreundlicher zu handlen sind (JAXB). Zu vollständigen Unterstützung der Sicherheitsstandards muss jedoch noch das Modul Apache Rampart mit Axis2 verknüpft werden. Erst dadurch kommen die WS-* Implementierungen und SAML hinzu. Der Nachteil dieses Frameworks ist jedoch, dass, aufgrund der Mächtigkeit, eine vergleichbar hohe Einarbeitung in die Materie notwendig ist. 5.3 Apache CXF Apache CXF entstand aus den Bestandteilen der beiden Projekte XFire von Codehaus und Celtix von IONA. Daher kam auch das Akronym CXF (CeltiXFire) zustande. Es ist ebenfalls ein Open Source Framework und setzt auf APIs zur Frontend Entwicklung von Services. Dieses Services funktionieren über eine Vielzahl von Protokollen wie SOAP, XML/HTTP, RESTful HTTP oder CORBA und funktioniert über diverse Transportwege wie HTTP, Java Messaging Service (JMS) und Java Business Integration (JBI). Das Hauptaugenmerk dieses Frameworks liegt dabei auf die leichte und intuitive Nutzung über simpel gestaltete APIs. Des Weiteren wird viel Wert auf Erweiterbarkeit, hohe Performanz und Integrierung in bestehende Systeme gelegt.

20 6 Fazit 18 6 Fazit Um Webservices abzusichern existieren zahlreiche Standards und diverses Framewoks, die diese Standards praktisch umgesetzt haben. In dieser Arbeit wurde zu Beginn die Grundlage zur Absicherung von XML-basierten Webservices erläutert, wie die Schutzziele Vertraulichkeit (mit XML-Encryption) und Integrität (mit XML-Signature) beim Austausch von Nachrichten über öffentliche Netze gewahrt werden können. Darauf aufbauend wurden die WS-* Standardisierungen der Organization for the Advancment of Structured Information Standards (OASIS) erläutert. Dabei ist klar geworden, dass dieses Standards eng miteinander verzahnt sind. So werden die Absicherungen, die mit WS-Security erreicht werden mit der WS-Policy definiert. Für ganze Kommunikationsabläufe wird mit WS- SecureConversation festgelegt, wie dort WS-Security am besten zum Einsatz kommt. Schließlich wurde noch die High-Level Technologie Security Assertion Markup Language (SAML) dargestellt und erläutert, inwiefern diese zur Absicherung von Webservices beiträgt. Durch das WS-Security Profil von SAML lassen sich strukturiert Authentifizierungs- und Autorisierungsinformationen mit Hilfe der WS- Security Standardisierung austauschen. Zum Abschluss dieser Arbeit wurden noch einige bekannte Frameworks aus Sicht der Sicherheit analysiert und dargestellt, um einen Überblick über deren Absicherung zu erhalten. Die drei Frameworks, die alle hier beschriebenen Techniken unterstützen, wurden schließlich noch kurz vorgestellt um bei der Wahl, für die eigene Architektur, zu einer besseren Entscheidungsfindung zu helfen und einen leichten Einstieg in die Materie zu gewährleisten.

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

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

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

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

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

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

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

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

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

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

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

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

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

Praktikum aus Softwareentwicklung 2. Web Services. Java Praktikum SS 2010 Gerald.Ehmayer@borland.com

Praktikum aus Softwareentwicklung 2. Web Services. Java Praktikum SS 2010 Gerald.Ehmayer@borland.com Web Services Java Praktikum SS 2010 Gerald.Ehmayer@borland.com 1 Web Services Einführung Definition, Eigenschaften, Anwendungen... JAX-RPC Überblick, Architektur... JAX Übersicht, Architektur Java Praktikum

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

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

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

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

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

(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

SSL/TLS und SSL-Zertifikate

SSL/TLS und SSL-Zertifikate SSL/TLS und SSL-Zertifikate Konzepte von Betriebssystem-Komponenten Informatik Lehrstuhl 4 16.06.10 KvBK Wolfgang Hüttenhofer sethur_blackcoat@web.de Motivation Sichere, verschlüsselte End-to-End Verbindung

Mehr

Java Web Services mit Apache Axis2 Entwickler

Java Web Services mit Apache Axis2 Entwickler Thilo Frotscher, Dapeng Wang, Marc Teufel Java Web Services mit Apache Axis2 Entwickler Vorwort 15 1 Einleitung 25 1.1 Entstehung 26 1.2 Unterstützte Standards 28 1.3 Was beinhaltet Axis2? 29 1.4 Warum

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

Verschlüsselung der Kommunikation zwischen Rechnern

Verschlüsselung der Kommunikation zwischen Rechnern Verschlüsselung der Kommunikation zwischen Rechnern Stand: 11. Mai 2007 Rechenzentrum Hochschule Harz Sandra Thielert Hochschule Harz Friedrichstr. 57 59 38855 Wernigerode 03943 / 659 0 Inhalt 1 Einleitung

Mehr

Programmierhandbuch SAP NetWeaver* Sicherheit

Programmierhandbuch SAP NetWeaver* Sicherheit Martin Raepple Programmierhandbuch SAP NetWeaver* Sicherheit Galileo Press Bonn Boston Inhalt Vorwort 13 2.1 Sicherheit und serviceorientierte Architekturen 24 2.1.1 Sicherheitsziele der Informationssicherheit

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

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

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

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

Mobile Agenten am Beispiel JADE (Java Agent DEvelopment Framework) Vorstellung in der Übung zu Konzepte Verteilter Systeme

Mobile Agenten am Beispiel JADE (Java Agent DEvelopment Framework) Vorstellung in der Übung zu Konzepte Verteilter Systeme Mobile Agenten am Beispiel JADE (Java Agent DEvelopment Framework) Vorstellung in der Übung zu Konzepte Verteilter Systeme Agenda Mobile Agenten allgemein JADE - Java Agent DEvelopment Framework Anwendungsfall

Mehr

Web Services stellen eine Integrationsarchitektur dar, die die Kommunikation zwischen verschiedenen Anwendungen

Web Services stellen eine Integrationsarchitektur dar, die die Kommunikation zwischen verschiedenen Anwendungen 9 3 Web Services 3.1 Überblick Web Services stellen eine Integrationsarchitektur dar, die die Kommunikation zwischen verschiedenen Anwendungen mit Hilfe von XML über das Internet ermöglicht (siehe Abb.

Mehr

PENETRATIONSTESTS BEI WEB- SERVICES

PENETRATIONSTESTS BEI WEB- SERVICES BSI GRUNDSCHUTZTAG 2014 PENETRATIONSTESTS BEI WEB- SERVICES Dominik Oepen 1 GS-WEB-SERVICES ABGRENZUNG Web-Services Schnittstelle zum automatisierten Aufruf Aufruf durch Programme (auch andere Web-Services)

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 - 1. Was ist SSL? SSL steht für Secure Socket Layer, ein Protokoll zur Übertragung

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

Markus Dopler Rainer Ruprechtsberger. Security und Trust Aspekte in Service-Orientierten Web-Applikationen

Markus Dopler Rainer Ruprechtsberger. Security und Trust Aspekte in Service-Orientierten Web-Applikationen Markus Dopler Rainer Ruprechtsberger Security und Trust Aspekte in Service-Orientierten Web-Applikationen SOSE: Vision Automatische Auswahl und Integration von angebotenen Services Inhalt Beispiel SOA

Mehr

SSL Algorithmen und Anwendung

SSL Algorithmen und Anwendung SSL Algorithmen und Anwendung Stefan Pfab sisspfab@stud.uni-erlangen.de Abstract Viele Anwendungen erfordern nicht nur eine eindeutige und zuverlässige Identifizierung der an einer Kommunikation beteiligten

Mehr

Client/Server-Systeme

Client/Server-Systeme Fachbereich Informatik Projektgruppe KOSI Kooperative Spiele im Internet Client/Server-Systeme Vortragender Jan-Ole Janssen 26. November 2000 Übersicht Teil 1 Das Client/Server-Konzept Teil 2 Client/Server-Architekturen

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

Oliver Olbrich Das ebxml Projekt Entstand 1999 in einer gemeinsamen Initiative von OASIS (Organisation for the Advancement of Structured Information Standards) und UN/CEAFACT (United Nations Center for

Mehr

Hauptseminar Internetdienste Prof. F. Schweiggert Sommersemester 2004 Universität Ulm. Web Services. Boto Bako

Hauptseminar Internetdienste Prof. F. Schweiggert Sommersemester 2004 Universität Ulm. Web Services. Boto Bako Hauptseminar Internetdienste Prof. F. Schweiggert Sommersemester 2004 Universität Ulm Web Services Boto Bako Inhaltsverzeichnis 1.Einführung und Motivation...3 2.Verwendete Standards...4 2.1.SOAP...5 2.2.WSDL...6

Mehr

Zusicherung von Qualitätskriterien bei WebServices. Dr. Bernhard Humm, Matthias Geiß sd&m-konferenz 2003 Web Services 17./18.07.

Zusicherung von Qualitätskriterien bei WebServices. Dr. Bernhard Humm, Matthias Geiß sd&m-konferenz 2003 Web Services 17./18.07. Zusicherung von Qualitätskriterien bei WebServices Dr. Bernhard Humm, Matthias Geiß sd&m-konferenz 2003 Web Services 17./18.07.2003 Agenda Verteilte Systeme am am Beispiel Beispiel Aspekte von Verteilung

Mehr

XML Signature Wrapping: Die Kunst SAML Assertions zu fälschen. 19. DFN Workshop Sicherheit in vernetzten Systemen Hamburg, 22.02.

XML Signature Wrapping: Die Kunst SAML Assertions zu fälschen. 19. DFN Workshop Sicherheit in vernetzten Systemen Hamburg, 22.02. XML Wrapping: Die Kunst SAML s zu fälschen Andreas Mayer Adolf Würth GmbH & Co. KG Künzelsau-Gaisbach Prof. Dr. Jörg Schwenk Lehrstuhl für Netz- und Datensicherheit Ruhr-Universität Bochum 19. DFN Workshop

Mehr

ÖSTERREICH RECHNET MIT UNS. Standard e-rechnungs-webservice (SERWS) - Ideen DI Philip Helger, BRZ 17.02.2015

ÖSTERREICH RECHNET MIT UNS. Standard e-rechnungs-webservice (SERWS) - Ideen DI Philip Helger, BRZ 17.02.2015 ÖSTERREICH RECHNET MIT UNS Standard e-rechnungs-webservice (SERWS) - Ideen DI Philip Helger, BRZ 17.02.2015 www.brz.gv.at BRZ GmbH 2015 AGENDA Ausgangsbasis Webservice bei E-RECHNUNG.GV.AT SERWS Ziele

Mehr

Friedrich. Kiltz. Java Webservices

Friedrich. Kiltz. Java Webservices Friedrich Kiltz Java Webservices Symbole.NET 379 @Action 279, 423 @Addressing 372 @BindingType 416 @Consumes 87 @Context 82, 88 @CookieParam 82, 88 @DefaultValue 82, 88 @DELETE 87 @Encoded 82, 88 @Endpoint

Mehr

Web Service Entwicklung mit Java. Sven Lindow

Web Service Entwicklung mit Java. Sven Lindow Web Service Entwicklung mit Java Sven Lindow 22.11.2006 Agenda Einleitung SOAP, REST, WSDL, UDDI Web Services mit Java JWSDP JAX-RPC, JAX-WS 2.0 AXIS, AXIS2 Web Services nutzen Google, Ebay Web Services

Mehr

Sicherheit in Webservices

Sicherheit in Webservices Hamid Saraha, Naima Fariss Fachgebiet Software Technik Fachbereich Informatik Technische Universität Darmstadt hasaraha@yahoo.de, nafariss@gmx.de Zusammenfassung. Um Webservices in Geschäftsprozesse sicher

Mehr

Grundlagen des Grid Computing

Grundlagen des Grid Computing Grundlagen des Grid Computing Webservices und Grid Computing Globus Toolkit 4 - Grundlagen ICA Joh.. Kepler Universität t Linz Eine Typische Grid-Applikation (Beispiel) VO Management Service Resource Discovery

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

Portalverbundprotokoll Version 2. S-Profil. Konvention PVP2-S-Profil 2.1.2 Ergebnis der AG

Portalverbundprotokoll Version 2. S-Profil. Konvention PVP2-S-Profil 2.1.2 Ergebnis der AG 1 Portalverbundprotokoll Version 2 S-Profil Konvention PVP2-S-Profil 2.1.2 Ergebnis der AG Kurzbeschreibung Das S-Profil von PVP2 verwendet SAML WebSSO für die Authentifizierung von Benutzern mit Webbrowser.

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

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

KompaSbilität zu Standards (WS- I) Contracts. Interfaces und Generics Umfangreiche AXribuSerung. Mehr Spielraum auf Transportebene

KompaSbilität zu Standards (WS- I) Contracts. Interfaces und Generics Umfangreiche AXribuSerung. Mehr Spielraum auf Transportebene Komponenten WCF (.NET Framework) WCF Verfeinerung und Reifung der ursprünglichen Version Geringere Unterschiede zu ASMX 2.0 (.NET 2.0) + WSE 3.0 Schwerpunkte KompaSbilität zu Standards (WS- I) Contracts

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

Digitale Signaturen für Ï Signaturzertifikate für geschützte email-kommunikation

Digitale Signaturen für Ï Signaturzertifikate für geschützte email-kommunikation Digitale Signaturen für Ï Signaturzertifikate für geschützte email-kommunikation Ein Großteil der heutigen Kommunikation geschieht per email. Kaum ein anderes Medium ist schneller und effizienter. Allerdings

Mehr

Denn es geht um ihr Geld:

Denn es geht um ihr Geld: Denn es geht um ihr Geld: [A]symmetrische Verschlüsselung, Hashing, Zertifikate, SSL/TLS Warum Verschlüsselung? Austausch sensibler Daten über das Netz: Adressen, Passwörter, Bankdaten, PINs,... Gefahr

Mehr

Web Services. XML, WSDL, SOAP und UDDI Einblicke und Ausblicke. 18.09.2002 J.M.Joller 1

Web Services. XML, WSDL, SOAP und UDDI Einblicke und Ausblicke. 18.09.2002 J.M.Joller 1 Web Services XML, WSDL, SOAP und UDDI Einblicke und Ausblicke 18.09.2002 J.M.Joller 1 Architektur von Web Services und ergänzende Technologien Inhalt Sicherheit WS-License und WS-Security Prozessfluss

Mehr

Bewertung der Einsatzmöglichkeiten von XML Sicherheitslösungen in mobilen Kommunikationsumgebungen. Ziel SSL/TLS. XML Signature/Encryption

Bewertung der Einsatzmöglichkeiten von XML Sicherheitslösungen in mobilen Kommunikationsumgebungen. Ziel SSL/TLS. XML Signature/Encryption 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

Technologien und Organisationskonzepte digitaler Identitäten Ein Überblick. Dr. Joachim Gerber

Technologien und Organisationskonzepte digitaler Identitäten Ein Überblick. Dr. Joachim Gerber Technologien und Organisationskonzepte digitaler Identitäten Ein Überblick Dr. Joachim Gerber INFORA-Kompetenzteam Informationssicherheit & Id-Management München, 14.06.2010 Agenda 1. Identität Begriff

Mehr

GeoXACML und SAML. Ubiquitous Protected Geographic Information. Dr. Andreas Matheus Universität der Bundeswehr München Andreas.Matheus@unibw.

GeoXACML und SAML. Ubiquitous Protected Geographic Information. Dr. Andreas Matheus Universität der Bundeswehr München Andreas.Matheus@unibw. GeoXACML und SAML Ubiquitous Protected Geographic Information Dr. Andreas Matheus Universität der Bundeswehr München Andreas.Matheus@unibw.de Was erwartet Sie in diesem Vortrag? Einleitung OpenGIS Web

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

E-Business Architekturen

E-Business Architekturen E-Business Architekturen Übung 3b Entwicklung eigener Service-Angebote 01.03.2015 Prof. Dr. Andreas Schmietendorf 1 Ziele der Übung Möglichkeiten zur Serviceimplementierung (ggf. auch Cloud) Umgang mit

Mehr

Sicherheit in Rich Internet Applications

Sicherheit in Rich Internet Applications Sicherheit in Rich Internet Applications Florian Kelbert 14.02.2008 Seite 2 Sicherheit in Rich Internet Applications Florian Kelbert 14.02.2008 Inhaltsverzeichnis Grundlagen Ajax und Mashups Adobe Flash-Player

Mehr

Enterprise Web-SSO mit CAS und OpenSSO

Enterprise Web-SSO mit CAS und OpenSSO Enterprise Web-SSO mit CAS und OpenSSO Agenda Gründe für SSO Web-SSO selbst gemacht Enterprise Web-SSO mit CAS Enterprise Web-SSO mit SUN OpenSSO Federation-Management Zusammenfassung Gründe für SSO Logins

Mehr

Daten-Kommunikation mit crossinx

Daten-Kommunikation mit crossinx Daten-Kommunikation mit Datenübertragung.doc Seite 1 von 8 Inhaltsverzeichnis 1 Einführung... 3 1.1 Datenübertragung an... 3 1.2 Datenversand durch... 3 2 X.400... 4 3 AS2... 4 4 SFTP (mit fester Sender

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

PKI (public key infrastructure)

PKI (public key infrastructure) PKI (public key infrastructure) am Fritz-Haber-Institut 11. Mai 2015, Bilder: Mehr Sicherheit durch PKI-Technologie, Network Training and Consulting Verschlüsselung allgemein Bei einer Übertragung von

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

Testbed II GDI NRW. Geodateninfrastruktur Nordrhein-Westfalen. Web Authentication & Authorization Service. Dokumentation Version 1.0.

Testbed II GDI NRW. Geodateninfrastruktur Nordrhein-Westfalen. Web Authentication & Authorization Service. Dokumentation Version 1.0. GDI NRW Geodateninfrastruktur Nordrhein-Westfalen Testbed II Web Authentication & Authorization Service Februar Dezember 2002 Dokumentation Version 1.0 Teilnehmer AED Graphics con terra FhG ISST GIA GIUB

Mehr

Entwicklung von Web-Anwendungen auf JAVA EE Basis

Entwicklung von Web-Anwendungen auf JAVA EE Basis Entwicklung von Web-Anwendungen auf JAVA EE Basis Java Enterprise Edition - Überblick Prof. Dr. Bernhard Schiefer Inhalt der Veranstaltung Überblick Java EE JDBC, JPA, JNDI Servlets, Java Server Pages

Mehr

Basistechnologien: Web-Services

Basistechnologien: Web-Services Alexander Rudolf Cloud-Computing Seminar Hochschule Mannheim WS0910 1/29 Basistechnologien: Web-Services Alexander Rudolf Hochschule Mannheim Fakultät für Informatik alexander.rudolf@stud.hs-mannheim.de

Mehr

Initiative»Elektronische Fallakte«

Initiative»Elektronische Fallakte« Deklarative Sicherheit zur Spezifikation und Implementierung der elektronischen FallAkte Workshop»Sichere Informationstechnologie für das Gesundheitswesen von morgen«gmds Jahrestagung 2010, Mannheim R.

Mehr

Spezifikationen und Voraussetzung

Spezifikationen und Voraussetzung Projekt IGH DataExpert Yellowbill Adapter Spezifikationen Voraussetzungen Datum : 22.08.2013 Version : 1.0.0.2 22.08.2013 Seite 1 von 7 Inhaltsverzeichnis 1 Einleitung...3 2 Architektur...3 2.1 Grundsätze

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

Ingo Schubert Technical Consultant Central Europe +49 89 540 523-01 ischubert@baltimore.com

Ingo Schubert Technical Consultant Central Europe +49 89 540 523-01 ischubert@baltimore.com 1 Ingo Schubert Technical Consultant Central Europe +49 89 540 523-01 ischubert@baltimore.com 2 Baltimore auf einen Blick Weltmarktführer für e security Produkte, Service, und Lösungen Weltweite Niederlassungen

Mehr

Java und XML/XML und Java. Mario Jeckle DaimlerChrysler Forschungszentrum Ulm mario.jeckle@daimlerchrysler.com mario@jeckle.de www.jeckle.

Java und XML/XML und Java. Mario Jeckle DaimlerChrysler Forschungszentrum Ulm mario.jeckle@daimlerchrysler.com mario@jeckle.de www.jeckle. Java und XML/XML und Java Mario Jeckle DaimlerChrysler Forschungszentrum Ulm mario.jeckle@daimlerchrysler.com mario@jeckle.de www.jeckle.de XML und Programmiersprachen... Java ist... Programmiersprache

Mehr

Security in.net 2.0. Thomas Stanek

Security in.net 2.0. Thomas Stanek Security in.net 2.0 2 Content 1. Verwendung 2. Überblick 3. Features im Detail a. Windows Accounts und SIDs b. Sichere Datenübertragung (SSL) c. X509 -Zertifikate d. Data Protection API (DPAPI) e. SecureStrings

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

Norm 410 Security Token Service

Norm 410 Security Token Service 1 Norm 410 Security Token Service 2 3 4 Release und Version Release 2 Version 2.5.0 (2.4.0) vom 25.04.2013, NAUS-Beschluss vom 14.06.2012 5 6 7 8 9 10 Status Arbeitsentwurf vom 12.08.2008 Potenzielle Norm

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

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

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

Karlsruher IT-Sicherheitsinitiative - 26. April 2001. "For your eyes only" Sichere E-Mail in Unternehmen. Dr. Dörte Neundorf neundorf@secorvo.

Karlsruher IT-Sicherheitsinitiative - 26. April 2001. For your eyes only Sichere E-Mail in Unternehmen. Dr. Dörte Neundorf neundorf@secorvo. Karlsruher IT-Sicherheitsinitiative - 26. April 2001 "For your eyes only" Sichere E-Mail in Unternehmen Dr. Dörte Neundorf neundorf@secorvo.de Secorvo Security Consulting GmbH Albert-Nestler-Straße 9 D-76131

Mehr

ESB. Open Source ESB: Mule Flightreservation. Res Gilgen Hochschule Luzern [Wählen Sie das Datum aus]

ESB. Open Source ESB: Mule Flightreservation. Res Gilgen Hochschule Luzern [Wählen Sie das Datum aus] ESB Open Source ESB: Mule Flightreservation Res Gilgen Hochschule Luzern [Wählen Sie das Datum aus] Inhalt 1. Open Source ESB: Mule... 2 1.1. Überblick... 2 1.1.1. Das Beispiel Zeigt:... 2 1.2. Installationsanleitung...

Mehr

Spezifikationen und Voraussetzung

Spezifikationen und Voraussetzung Projekt IGH DataExpert Paynet Adapter Spezifikationen Voraussetzungen Datum : 21.07.08 Version : 1.0.0.2 21.07.2008 Seite 1 von 7 Inhaltsverzeichnis 1 Einleitung... 3 2 Architektur... 3 2.1 Grundsätze

Mehr

Softwareentwicklung mit Enterprise JAVA Beans

Softwareentwicklung mit Enterprise JAVA Beans Softwareentwicklung mit Enterprise JAVA Beans Java Enterprise Edition - Überblick Was ist J2EE Java EE? Zunächst mal: Eine Menge von Spezifikationen und Regeln. April 1997: SUN initiiert die Entwicklung

Mehr

Datenübertragungsportal

Datenübertragungsportal Datenübertragungsportal seite zwei Inhalt Inhalt seite zwei Datenübertragungsportal seite drei Erreichte Schutzziele seite acht seite drei Datenübertragungsportal Die Firmengruppe Melter stellt Ihren Kunden

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

VPN. Virtuelles privates Netzwerk. Vortrag von Igor Prochnau Seminar Internet- Technologie

VPN. Virtuelles privates Netzwerk. Vortrag von Igor Prochnau Seminar Internet- Technologie VPN Virtuelles privates Netzwerk Vortrag von Igor Prochnau Seminar Internet- Technologie Einleitung ist ein Netzwerk, das ein öffentliches Netzwerk benutzt, um private Daten zu transportieren erlaubt eine

Mehr

Das Interceptor Muster

Das Interceptor Muster Das Interceptor Muster Implementierung des Interceptor Musters basierend auf OSGi and Friends Benjamin Friedrich Hochschule für Technik und Wirtschaft des Saarlandes Praktische Informatik - Entwurfsmuster

Mehr

Verteilte Systeme. Sicherheit. Prof. Dr. Oliver Haase

Verteilte Systeme. Sicherheit. Prof. Dr. Oliver Haase Verteilte Systeme Sicherheit Prof. Dr. Oliver Haase 1 Einführung weitere Anforderung neben Verlässlichkeit (zur Erinnerung: Verfügbarkeit, Zuverlässigkeit, Funktionssicherheit (Safety) und Wartbarkeit)

Mehr

Grundlagen. AAI, Web-SSO, Metadaten und Föderationen. Wolfgang Pempe, DFN-Verein pempe@dfn.de

Grundlagen. AAI, Web-SSO, Metadaten und Föderationen. Wolfgang Pempe, DFN-Verein pempe@dfn.de Grundlagen AAI, Web-SSO, Metadaten und Föderationen Wolfgang Pempe, DFN-Verein pempe@dfn.de DFN-AAI IdP-Workshop, 24./25. Juni 2015, HS Amberg-Weiden Was ist DFN-AAI? AAI Authentifizierung Autorisierung

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

Anlage 3 Verfahrensbeschreibung

Anlage 3 Verfahrensbeschreibung Anlage 3 Verfahrensbeschreibung Stand September 2015 1 INHALTSVERZEICHNIS 1 EINLEITUNG... 2 2 SYSTEMVORAUSSETZUNGEN... 3 2.1 Technische Voraussetzung beim Kunden... 3 2.2 Ausstattung des Clients... 3 3

Mehr

Seminar Internet-Technologie

Seminar Internet-Technologie Seminar Internet-Technologie Zertifikate, SSL, SSH, HTTPS Christian Kothe Wintersemester 2008 / 2009 Inhalt Asymmetrisches Kryptosystem Digitale Zertifikate Zertifikatsformat X.509 Extended-Validation-Zertifikat

Mehr

Sichere Kommunikation für SOAP-basierte Web Services

Sichere Kommunikation für SOAP-basierte Web Services Whitepaper SOA Security Framework Sichere Kommunikation für SOAP-basierte Web Services Holger Junker, BSI, soa@bsi.bund.de Die Sicherheitsanforderungen an SOA Infrastrukturen und den darin stattfindenden

Mehr

Zustandsgebundene Webservices

Zustandsgebundene Webservices Zustandsgebundene Webservices Präsentation ausgewählter Problemstellungen der Informatik Markus Oertel oer@uni-paderborn.de Universität Paderborn 25. September 2005 Zustandsgebundene Webservices Seite

Mehr

Unterhalten Sie sich leise mit Ihrem Nachbarn über ein aktuelles Thema. Dauer ca. 2 Minuten

Unterhalten Sie sich leise mit Ihrem Nachbarn über ein aktuelles Thema. Dauer ca. 2 Minuten Versuch: Eigenschaften einer Unterhaltung Instant Messaging Unterhalten Sie sich leise mit Ihrem Nachbarn über ein aktuelles Thema. Dauer ca. 2 Minuten welche Rollen gibt es in einem IM-System? Analysieren

Mehr