SECURITY WEB APPLICATION. mit Scala. Plus CD! Stellenmarkt 61 Performance-Killern auf der Spur 64. Funktionale Programmierung.

Größe: px
Ab Seite anzeigen:

Download "SECURITY WEB APPLICATION. mit Scala. Plus CD! Stellenmarkt 61 Performance-Killern auf der Spur 64. Funktionale Programmierung."

Transkript

1 6.09 Plus CD! Stellenmarkt 61 Performance-Killern auf der Spur 64 Deutschland 7,50 Österreich 8,60 Schweiz sfr 15,80 Java Magazin Java Architekturen SOA Agile CD-Inhalt WebCastellum Spring Integration JSFUnit GA Enterprise D Marc Gille: SOA, SaaS und ich? Spring Integration Werkzeugkiste für EAI 56 Web Grails 1.1 Neues vom Groovy-Framework 32 Architektur Lose gekoppelte Systeme Die typischen Fehler vermeiden 99 SOA Center Sicher ist sicher JGAP ScalaTest Selenium HtmlUnit 2.4 Alle CD-Infos 3 SOA Security unter der Lupe 83 WEB APPLICATION SECURITY Was JEE-Architekten beachten müssen 46 Funktionale Programmierung mit Scala Das Tutorial 38 Bauen und Testen mit Grails 23 Die voll funktionsfähige Blog-Applikation mit Grails ist fertig, jetzt kommt die Kür. Das Tutorial zeigt Testmöglichkeiten sowie die unterstützten Build-Systeme. Dann klappt s auch mit der Qualitätssicherung.

2 SOA aus dem wahren Leben Teil 8 SOA Center SOA Security In klassischen Systemen sind Sicherheitsanforderungen durch ihre lokale Beschränkung meist relativ einfach beherrschbar. Deren Komplexität erhöht sich in der verteilten Systemlandschaft einer SOA: Sicherheit beschränkt sich hier nicht nur auf eine Applikation oder eine Anwendungsdomäne, sie muss anwendungsund geschäftsprozessübergreifend wirken. von Berthold Maier, Hajo Normann, Bernd Trops, Clemens Utschig-Utschig und Torsten Winterberg ur Realisierung dieser übergreifenden Sicherheitsanforderungen wurden zahlreiche Sicherheitsstandards geschaffen. Dazu zählen WS-Federation, WS-Secure- Conversation, WS-SecurityPolicy, WS- Trust, XML-Encryption, XKMS, XML- Signature, SAML1, SAML2 und viele mehr. Heute unterstützt kein Produkt oder Open-Source-Framework alle diese Standards vollständig. Zudem kommt es nach unserer Erfahrung oft zu Inkompatibilitäten, wenn ein SOA-Produkt oder Web Service Stack außerhalb seines kleinen Ökosystems kommunizieren muss. Kein Wunder, wenn nach ersten Absicherungsversuchen und guten Vorsätzen viele Projektverantwortliche durch explodierende Aufwände genervt nach beherrschbaren Alternativen fragen. Nicht selten wird dann auf unflexible, eigenentwickelte Lösungen zurückgegriffen, in denen schnell gefährliche Antipatterns implementiert werden, wie beispielsweise die Übertragung von Benutzername und Passwort im fachlichen Payload. Wir wollen in diesem Teil der Artikelserie nicht die zahllosen Standards beschreiben, sondern vielmehr an typischen Problemstellungen diskutieren, welche Art von Sicherheit für welchen Zweck relevant ist, wie diese implementiert wird und welche Standards dazu sinnvoll eingesetzt werden können. Damit wollen wir dem SOA- Architekten einige Hinweise geben, wie er verantwortungsvoll und auf der Basis erprobter Best Practices dem Thema Security gerecht werden kann. Wie viel Sicherheit soll es denn sein? Sicherheit nimmt aufgrund der weitreichenden Vernetzung durch SOA zwar eine enorm wichtige Rolle ein, sie ist jedoch nicht für alle Anwendungsgebiete und Architekturebenen in gleichem Maße notwendig. Es gilt deshalb zunächst für das Unternehmen und die betroffenen Abteilungen die internen und externen Sicherheitsanforderungen zu definieren. Dabei ist konzeptionell zu erarbeiten, wie diese mit den vorhandenen Mitteln und Standards möglichst einfach umgesetzt werden können. Mittels einer Risikoanalyse wird zu Beginn eines SOA-Projekts untersucht, wie wahrscheinlich das Eintreten eines bestimmten Schadens ist und welche negativen Folgen der Schaden mit sich bringt. So können der Aufwand und die Performancebelastungen, die mit bestimmten Security-Lösungen einhergehen, gegen die erreichte Absicherung abgewogen werden letztendlich ist dies auch eine monetäre Entscheidung. Neben der unternehmensweiten Risikoanalyse beeinflusst oft die Gesetzeslage die Sicherheitsarchitektur. Bedenkt man, dass seit geraumer Zeit auch Vorstände und Geschäftsführer persönlich für Versäumnisse und mangelnde Risikovorsorge verantwortlich gemacht werden können, so wird Sicherheit mehr und mehr zur Chefsache. Eine angemessene, flexible und vor allem durchgängige Sicherheitsarchitektur, die den Anforderungen der Sicherheitsrichtlinien, beispielsweise ISO [1] oder der BSI-Standard 100 [2] des öffentlichen Bereiches, genügt, ist also ein wichtiger Aspekt einer SOA. Security spielt auch in sicheren Umgebungen eine Rolle: In vielen Organisationen wird das Thema Security als nicht relevant betrachtet, da man sich im Kontext einer trusted Zone, etwa innerhalb eines Intranets, befindet und die Anwendungen hinter den Services bereits eine Art der Sicherheit implementieren. Hier sollte man jedoch bereits in der SOA- Referenzarchitektur beachten, dass auch orchestrierte Dienste (in BPEL, auf dem ESB, allgemein in Composite Services) gegebenenfalls erst zusammengesetzt geschäftskritisch wirken und auf höherer Ebene abgesichert werden müssen. Weiter sind wichtige Dienste z. B. davor zu schützen, massenhaft aufgerufen zu werden, damit sie ihre Zusicherungen zur Antwortzeit deterministisch erfüllen können. Andere Dienste können javamagazin

3 SOA Center SOA aus dem wahren Leben Teil 8 vertrauliche Daten enthalten, die auch innerhalb einer trusted Zone an keiner Stelle im SOA-Verbund in falsche Hände geraten dürfen, was ein nahtloses Ineinandergreifen der implementierten Sicherheit erfordert. Welche Arten von Sicherheit gibt es? In der IT-Sicherheit gliedert man das Bedrohungspotenzial in folgende Kategorien: Den Verlust der Verfügbarkeit, der Vertraulichkeit und/oder der Integrität. Beim Übertragen von Daten und Dokumentstrukturen kommt noch der Verlust der Authentizität (Echtheit) hinzu, was innerhalb einer SOA besondere Bedeutung gewinnt [2]: Verfügbarkeit: Dem Service Consumer stehen die Dienste (Services, Anwendungen, Systeme) zu den geforderten Zeitpunkten wie vereinbart ohne Beeinträchtigung des Geschäfts zur Verfügung. Vertraulichkeit: Schutz vor unbefugtem Zugriff auf vertrauliche Informationen, was bei deren Austausch eine neue Dimension der Schutzbedürftigkeit gewinnt. Integrität: Auch als Verlässlichkeit bezeichnet. Sicherstellung, dass Nachrichteninhalte vollständig und unverändert von Provider zum Consumer und umgekehrt gelangen. Authentizität: Der Nutzer ist der, für den er sich ausgibt und stellt keine anonyme Entität dar. Wie erwähnt sind die IT-Sicherheitsmerkmale mit Einzug der neuen serviceorientierten Architektur in die Referenzarchitektur aufzunehmen und in deren Kontext neu zu bewerten. Unsere virtuelle Autovermietung RYLC [5] hat beispielsweise folgende Sicherheitsrichtlinien für SOA aufgesetzt: Verfügbarkeit Zertifikate verhindern Attacken: In einer serviceorientierten Architektur werden die Services gewöhnlich in einer mehr oder minder geschützten Netzdomäne veröffentlicht. Business Services, die gewöhnlich einem breiten Publikum innerhalb oder sogar außerhalb einer Organisation zugänglich gemacht werden, sind den typischen Internetattacken wie Denial of Service ausgesetzt. Diese Art der Bedrohung wird gewöhnlich durch Netzmaßnahmen abgesichert. Als typische Sicherungsvariante kommt dabei oft das SSL-Protokoll in Verbindung mit X.509-Clientzertifikaten zum Einsatz. Hiermit wird der Nutzerkreis auf die Besitzer des Zertifikats reduziert und das Bedrohungspotenzial reduziert. Weitere typische Maßnahmen sind die IP-Prüfung, Messung der Aufrufhäufigkeit und Sperrung bei Überschreiten eines Schwellenwertes. Sicherstellen der Verfügbarkeit: Die öffentlichen Schnittstellen müssen oft 24/7 verfügbar sein. Um dies sicherzustellen, muss die SOA-Infrastruktur skalierbar und clusterfähig ausgelegt sein. Sie muss ebenso in der Lage sein, sich selbst zu beobachten und das drohende Verletzen der Verfügbarkeitsanforderungen erkennen zu können, sich selbst zu heilen oder einen Administrator zu benachrichtigen. Hilfreich ist hier der Einsatz eines geeigneten, hochverfügbaren ESB-Produkts als Entry Point aller Serviceaufrufe. Zu bedenken ist, dass die geforderte Clusterfähigkeit in Verbindung mit Reliability durch die komplexe Materie nur von wenigen SOA/ESB-Infrastrukturen ausreichend unterstützt wird. Die sorgfältige Auswahl geeigneter Produkte und vor allem deren Zusammenspiel ist entscheidend, um die geforderte Verfügbarkeit sicherzustellen. Besonders bei Open-Source-Projekten stellt das Zusammenspiel zwischen unterschiedlichen Werkzeugen oft eine Herausforderung dar, da deren Integration nicht bei dem Hersteller einer zusammenhängenden Suite liegt, sondern bei den Entwicklerteams, die damit arbeiten. Aus diesem Grund sollte bei der Auswahl darauf geachtet werden, dass es ggf. Support und Weiterentwicklungsgarantien von Dritten für die gesamte eingesetzte Suite gibt was gerade auch bei Open Source ein beliebtes Geschäftsmodell darstellt. Schnelle Reaktion auf Auffälligkeiten und Fehler sind in einer SOA-Landschaft zentrale Aufgaben. Hier haben sich so genannte Softwareagenten als Abnehmer etabliert, die an den Entry Points zum ESB als Querschnittsaspekte platziert werden und Informationen an zentrale Überwachungssysteme mit den typischen Protokollen wie z. B. SMTP liefern. Hierfür gibt es ausgereifte Produkte wie Nagios, Hyperic, Open- View, IBM Tivoli, Patroll, Oracle Enterprise Manager etc., die alle Komponenten wie Applikationsserver, Webserver, Loadbalancer usw. im SOA-Verbund überwachen können. Vertraulichkeit Unterschiedliche Anforderung je nach Servicekategorie: Vertraulichkeit ist bei externen Serviceaufrufen (Business Services) fast immer eine unabdingbare Anforderung. Für Serviceaufrufe aus dem Intranet auf unterer Kategorieebene (z. B. Business Entity Services (BES) oder Business Rule Service (BRS)) genügen bei nicht geschäftskritischen Services oft auch vertragliche und nicht technische Vertrauensbeziehungen. Die Vertrauensprüfung erfolgt deshalb meist auf oberster und externer Serviceebene also auf der Ebene von Business Activity Services (BAS) und Business Process Services (BPS). Verschlüsselung ermöglicht Vertraulichkeit: Erreicht wird Vertraulichkeit, also der Schutz vor unerlaubtem Zugriff auf sensible Daten, durch Verschlüsselung. Bei Verschlüsselung (Chiffrieren) handelt es sich um das Verfahren der Abbildung einer im Klartext vorliegenden Nachricht unter Zuhilfenahme eines Schlüssels in eine Geheimnachricht, die nur durch diejenigen entzifferbar sein soll, die den Schlüssel kennen [7]. Aufgrund der Problematik der Schlüsselübertragung und dessen Geheimhaltung, hat sich das asynchrone RSA-Verfahren [8] mit privatem und öffentlichem Schlüssel (Private- und Public-Key) durchgesetzt. Herausforderung Schlüsselmanagement: Da in einer SOA zur Verschlüsselung (Vertraulichkeit) und zum Signieren (Authentizität) die Nachrichtenschlüssel vorgehalten werden müssen, ist in einer SOA-Infrastruktur eine effiziente Schlüsselverwaltung notwendig. Leider werden allzu oft Schlüssel wild abgelegt und in der Infrastruktur 84 javamagazin

4 verteilt. Dies führt immer wieder zu Ausfällen, da bekanntlich die ausgestellten Schlüsselzertifikate ein Ablaufdatum besitzen und die Administratoren den Überblick verlieren, wann und wo welche Schlüssel abgelegt und zu erneuern sind. In einer gut strukturierten SOA wird idealerweise eine zentrale Schlüsselverwaltung implementiert und diese aus den Services oder Security-Agenten per XKMS [4] angesprochen, was wir weiter unten noch im Detail behandeln. Antipattern SSL in Web Services : Der Reflex, SSL zur Protokollabsicherung zu verwenden, ist bei einer End- 2End-Absicherung nicht zielführend. Mit SSL wird bekanntlich nur der Weg zwischen zwei Knotenpunkten abgesichert. Auf den Zwischenknoten kann innerhalb des ESB oder BPEL sein bis zum eigentlichen Backend-Service sind die Nachrichten nicht verschlüsselt und somit von Unbefugten einsehbar bzw. veränderbar. Bedingt durch den einfachen Betrieb der SSL-Technologie ist diese jedoch eine gängige Absicherungsart zwischen externem Konsumenten und Business Service der oberen Ebene; intern wird jedoch aufgrund der geltenden Richtlinien oft auf eine Nachrichtenverschlüsselung verzichtet. Wird aufgrund hochsensibler Daten dennoch eine End2End-Sicherheit gefordert, ist die Nachricht selbst, also die SOAP- oder REST-Nachricht, zu verschlüsseln, und nicht nur das Verbindungsprotokoll. Wird nun die gesamte Nachricht (Payload) verschlüsselt, kann dies im ESB oder BPEL zu Problemen führen, da die Inhalte nicht zur Logiksteuerung (z. B. Content-based Routing) verwendet werden können. In der Praxis hat sich deshalb die Teilverschlüsselung der kritischen und schützenswerten Inhalte (z. B. nur das eine Element mit den Provisionsdaten) als Best Practice bewährt. Integrität Versiegeln der Nachricht: Vollständigkeit und Unveränderbarkeit einer Nachricht kann am einfachsten sichergestellt werden, wenn ein Siegel darauf gesetzt wird. Das aufgebrochene Siegel deutet auf eine Veränderung der Nachricht hin, was den Empfänger zur Protokollierung und Abweisung der Nachricht bewegen sollte. Ein solches Siegel wird technisch in zwei Schritten hergestellt: Mithilfe eines sicheren Hash-Algorithmus wird aus der Nachricht als Eingabeparameter ein eindeutiger Wert berechnet, der auch Message Digest genannt wird. Zur Berechnung hat sich der Secure Hash Algorithm 1 (SHA1 normiert in RFC3174) durchgesetzt. Im zweiten Schritt wird der Digest zusätzlich verschlüsselt und mit dem Zertifikat und der Nachricht des Senders verknüpft. Verwendet wird dazu die in der W3C-XML-Encryption- Spezifikation [3] definierte Vorgehensweise. Die Programmierung mit dem doch komplexen API entfällt glücklicherweise beim Einsatz eines Web Service Stacks wie z. B. Metro, CXF oder idealerweise beim Einsatz einer Policybasierten Security-Lösung, deren Funktionsweise wir im Detail noch erläutern. Authentizität Mit dem Begriff Authentizität wird die Eigenschaft bezeichnet, die gewährleistet, dass ein Kommunikationspartner tatsächlich derjenige ist, der er vorgibt zu sein. Mit Authentizität wird im SOA-Umfeld oft naiv umgegangen, wir werden daher genauer beleuchten, was schief gehen kann und stellen dann stabilere Lösungen vor. Anti-Pattern Benutzername/Passwortauthentifizierung : SOA-Entwickler sind keine Security-Experten. Mit einer entsprechenden Anforderung konfrontiert und unter Zeitdruck geschieht es schnell, dass Security-Aspekte in Dienste hineinprogrammiert werden, ohne die technischen Implikationen zu berücksichtigen. Eine der am häufigsten beobachteten Programmierfallen in diesem Sinne ist der Authentifizierungsmechanismus mit Username und Passwortabsicherung: Hier wird, wie in der Web-Service-Security-(WSS-)Spezifikation vorgegeben, sowohl der Username als auch das Password explizit im SOAP Header an den aufgerufenen Service übertragen. Handelt es sich um den initialen Serviceaufruf, stellt dies meist kein großes Problem dar. Denken wir jedoch daran, dass wir aus Flexibilitätsgründen Services zu Prozessen (z. B. per BPEL) orchestrieren wollen, die dann Anzeige

5 SOA Center SOA aus dem wahren Leben Teil 8 in einer komplexen Aufrufkette stehen. Eine Username- und Passwortabsicherung würde dann bedeuten, dass Nachrichten vom Prozessinitiator zu jedem potenziellen Service des Geschäftsprozesses neben dem Usernamen auch das Passwort im Klartext enthalten müssten. Alternativ müssten die Services/ Agenten das Passwort jeweils ermitteln. Beide Umstände sind administrativ und sicherheitstechnisch inakzeptabel. Es stellt sich daher die Frage, wie ein Sicherheitskontext durchgängig, ohne erneute Passworteingabe, durch die Prozesslandschaft getragen werden kann. Zusicherung einer ID mittels Token und Zertifikaten: Als Voraussetzung für eine stabile Authentifizierung sollten alle Nutzer von zu sichernden Services Menschen und Softwarebausteine eine eindeutige Identitätskennung erhalten. Für die Weiterleitung der Aufruferidentität hat sich vor allem in der SOA-Welt das so genannte Token-basierte Sicherheitsverfahren etabliert. Dazu meldet man sich an einem zentralen Authentifizierungsdienst, typischerweise über ein Portal SSO Login an, das die Credentials des Nutzers prüft etwa durch Passworteingabe, Zertifikat, Chipkarte oder sonstige biometrische Identifizierungsmechanismen. Der Authentifizierungsdienst erzeugt ein Token, das ein X.509-Zertifikat, ein Kerberos-Ticket oder auch eine SAML- Zusicherung (Assertion) sein kann, und verpackt dieses in das standardisierte SAML- (Security-Assertion-Markup- Language-)Sicherheitsaustauschformat [7]. Dieses enthält u. a. die Nutzeridentität man spricht auch vom Subject, die dann zur Sicherheitsabfrage und zur Protokollierung vom Eintrittspunkt bis in das Endsystem durchgereicht wird. SAML standardisiert also die XML-Sicherheitsstruktur, die zum Austausch von Sicherheitsinformationen innerhalb und auch außerhalb der Web-Service-Security- Spezifikation (im WSS SOAP Header) benutzt werden kann. Die mit SAML gegebene Interoperabilität auf Security-Ebene erlaubt erst den Aufbau einer unternehmensübergreifenden Sicherheitskommunikation, weshalb Security mit SAML von Beginn an in die Architekturfestlegung verankert werden sollte. Authentifizierung und Security-Kontext-Übermittlung: Zur Übermittlung einer Identität in einer SOAP-Nachricht hat sich der Standard WS-Security in Verbindung mit SAML durchgesetzt. Dieser beschreibt u. a., wie in einem SOAP Header eine standardisierte XML- Struktur mit Identifikationsinformationen verpackt und übertragen wird. Nutzung des Usernamen im Fachcode: Verwendet der Service zur Umsetzung der Sicherheitsrichtlinien einen Querschnittsaspekt, der für den fachlichen Serviceimplementierer neutral eingewoben wird und alle Security- Aufgaben vorgeschaltet abhandelt, stellt sich die nächste Frage: Wie bekommt die fachliche Serviceimplementierung oder die funktionsimplementierende Komponente die Informationen, um welchen User es sich tatsächlich handelt? Verlangt wird dies beispielsweise, wenn die implementierende Komponente aus fachlichen Gründen nur dem Anwender zugeordnete Daten zurückliefern bzw. ändern darf. Beispiel: der Zugriff eines Services auf eine Datenbank setzt letztlich den korrekten User voraus. Die Übergabe des Benutzernamens im Payload parallel zum Security Header ist auch hier die denkbar schlechteste, jedoch am häufigsten vorgefundene Methode. In dem Fall können die Standardmechanismen der Infrastruktur kaum genutzt und der Serviceaufrufer oder auch die Servicemediatoren können die Anwenderdaten sehr einfach manipulieren und damit Zugriff auf unberechtigte Inhalte erlangen. Es muss also der Security Context in die Komponente getragen werden. Ideal ist, wenn der Service selbst als JAVA-EE-Komponente [6], Spring-Komponente oder als Agent implementiert wird. Hier erfolgt das Propagieren des Sicherheitskontexts nach Konfiguration automatisch. Obwohl dieses Vorgehen logisch erscheinen mag, sehen wir täglich, dass dieses Designprinzip verletzt wird und der Username oft parallel, beispielsweise als Service- oder Methodenargument, mit in die Anwendung übermittelt wird. SOA-Sicherheitsinfrastruktur Wir haben bereits gesehen, dass es problematisch ist, Serviceimplementierungen und Security-Aspekte zu vermischen. Im Sinne des Separation-of-Concern- Prinzips sollte Fachlogik und technische Logik (hier Security-bezogen) strikt getrennt werden: Die Skills, die für diese Aspekte nötig sind, unterscheiden sich sehr von der Serviceprogrammierung, weshalb eine Mischung zu schwer wartbaren Services führen würde. Daher sollte beim Etablieren einer SOA-Sicherheitsarchitektur eine klare Trennung zwischen Anwendungs- und Sicherheitslogik auf allen Ebenen erzwungen werden. Realisiert wird dieser Querschnittsaspekt dann meist durch Umsetzungen der Designpattern-Fassade, Proxy, Wrapper oder aber mithilfe von Policies, sodass bei Implementierung eines Services die Fachlogik isoliert dasteht und je nach Anforderung konfigurierbar mit unterschiedlichen Security-Implementierungen umschlossen werden kann. Da wir dieses Prinzip der Sicherheitsrealisierung als wichtig empfinden, wollen wir im folgenden Abschnitt näher darauf eingehen, wie Security-Aspekte durch eine Policy-basierte Sicherheitsarchitektur isoliert umgesetzt werden können. Aspektorientierte Security mit Policy-based Management Policy-based Management (PBM) zum entkoppelten und aspektorientierten Sicherheitsmanagement setzt sich neben der vorhanden Security in den Anwendungskomponenten (z. B. Security im WS-Stack) aufgrund der schwer wartbaren Verteilung von Sicherheitsrichtlinien und der immer komplexer werden Verwaltung auch im SOA-Umfeld immer mehr durch. Generell wird mit PBM das gesamte querschnittliche IT-Systemmanagement sowie dessen Konfiguration unter Verwendung von Policies und Agenten bezeichnet. Policies definieren Verhaltensregeln und werden meist in einem zentralen Repository erstellt und abgelegt. Die in den Policies enthaltenen Regeln werden dann an den sicherheitsrelevanten Punkten im System von Agenten umgesetzt. Bei Vorhandensein einer Verschlüsselungs-Policy, die dynamisch vom Policy Decision Point (PDP) geliefert wird, würde beispielsweise ein im Web Service platzierter Agent die 86 javamagazin

6 SOAP-Nachricht mit den gegebenen Informationen verschlüsseln. Der Web Service selbst hat in diesem Fall weder Sicherheit zu implementieren noch die komplexen Security-Artefakte in den Java-EE-Deployment-Deskriptoren zu konfigurieren. Damit muss der Web Service bei einer Änderung der Sicherheitsrichtlinien weder angepasst noch neu deployt oder durchgestartet werden. Typische Produkte sind der IBM Tivoli Security Operations Manager, der WebService Manager (OWSM) der Firma Oracle oder die integrierte Policy-Verwaltung in der Open-Source-SOA-Suite SOPERA. Funktionsweise der Agenten: Innerhalb eines PBM kommt meist das Agentenkonzept zur Realisierung der querschnittlichten Aspekte zum Einsatz. Agenten fungieren als Policy Enforcement Points, auch kurz PEP genannt, und werden innerhalb der Laufzeitkomponenten im Proxy-Code zwischen Aufrufer und Ausführer platziert. Sie ermitteln über den Policy Decision Point (PDP) vom zentralen Policy Repository die konfigurierten und notwendigen Sicherheitsmerkmale und führen sie vor dem eigentlichen Serviceaufruf aus. Neben Authentifizierung, Autorisierung und Verschlüsselung können die Agenten natürlich auch SOAP-Nachrichten signieren und Protokollierungsaktionen ausführen. Die dabei genutzten Policies werden heute meist durch den XML- Standard WS-Policy [9],[10] beschrieben und in einem zentralen Governance Repository durch den Policy Administration Point (PAP) gepflegt. Innerhalb des PBM ist der PEP für die Interpretation und Durchsetzung der Autorisierungsentscheidungen der vom PDP gelieferten Policies im System oder Service verantwortlich. Als Standardsprache zur Abfrage der Zugriffskontrolle hat sich die extensible Access Control Markup Language (XACML) durchgesetzt. Auf diese wird auch innerhalb von SAML zum Austausch der Autorisierungsinformationen zurückgegriffen, da XACML ein SAML-Profil definiert. Als Policy Decision Point (PDP) wird die Komponente bezeichnet, die die Autorisierungsentscheidungen anhand der ihr bereitgestellten Sicherheits-Policies trifft. Gewöhnlich nimmt ein PDP Meldungen von PEPs entgegen und ermittelt aus einem Repository die anzuwendende Policy. Der PDP erkennt und behebt dabei zur Laufzeit Konflikte bei mehreren vorhanden überschneidenden Policies. Der Policy Decision Point kann somit auch als Legislative (Gesetzgeber) innerhalb des Access Managements bezeichnet werden. Die Verteilung der Policies nach Änderungen oder Erweiterungen erfolgt je nach Anforderung durch einen Pushoder Pull-Mechanismus. Die Verwendung der Push-Methode, bei der vom Administrationsserver die Änderungen in den PDP getragen werden, findet bevorzugt Verwendung. Da durch PBM das physische Service-Deployment bei Änderungen einer Policy entfällt, wird eine Governance-unterstützende Administrationskomponente, in dem Umfeld PAP Policy Administration Point genannt, mit Workflow-Mechanismen, inklusive zeitabhängig geregelter Verteilung und Approval-Routinen für den geplanten Rollout und Aktivierung der Policies notwendig. Die Verwendung des Agentenkonzepts hat den unerwünschten Nebeneffekt, dass die Aufrufpipelines der Services verändert werden und somit ein unerwünschter Systemeingriff (Implementierung oder Konfiguration des WS wird durch den Agenten verändert) vorgenommen werden muss. Es wird deshalb neben dem Agentenkonzept oft auch das Konzept der Sicherheitsgateways angewandt. Die Sicherheit wird hierbei durch ein vorgeschaltetes und zentral platziertes Sicherheitsgateway als Proxy-Komponente implementiert, die alle Aufrufe abfängt, die Policies ausführt und dann an den Originalservice weiterleitet. Dieses Konzept ist jedoch in Bezug auf Sicherheit nicht ganz so robust wie das der Agenten: Zwischen Sicherheitsgateway und Service liegt eine Netzstrecke, auf der potenziell eine Manipulation stattfinden könnte. Das Agentenkonzept integriert sich dagegen in den Service und ist somit sicherer. Sicherheitsgateways können den Sicherheitskontext nicht in den Service und die implementierenden Komponenten tragen. Ein Agent kann dagegen einen Sicherheitskontext Anzeige

7 SOA Center SOA aus dem wahren Leben Teil 8 der eingegebenen Kreditkartennummer über einen weiteren extern abgesicherten Service vom Kartenprovider die Bonität geprüft. Im positiven Fall wird im Rental- System die Buchung getätigt und dem Kunden wird per Mail eine Referenz-ID als Schlüssel für weitere Anfragen und zur Abholung übermittelt. Abb. 1: Security im Rent-Your-Legacy-Car-(RYLC-)Beispiel JAVA-EE-konform oder anwendungsspezifisch aufbauen. Sicherheitsgateways generieren durch die zentral platzierte Schleuse generell eine höhere Systemlast, die mit berücksichtigt werden muss. Public Key Infrastruktur (PKI) via XKMS: Zur Sicherstellung und Prüfung der Authentizität kommt gewöhnlich das asymmetrische Kryptosystem RSA zum Einsatz. Die Verwaltung der öffentlichen Schlüssel wird dabei in einer Public Key Infrastructure (PKI) bewerkstelligt. Innerhalb einer SOA liegt es nun nahe, die Schlüssel über entsprechende Services zu verwalten und nicht lokal verteilt an unterschiedlichen Stellen im Dateisystem oder in all den parallel betriebenen Applikationsservern abzulegen. Genau dafür wurde die XML Key Management Specification [4] vom World-Wide-Web- Konsortium definiert. XKMS definiert ein Protokoll, das die Funktionen einer PKI für Services zur Verfügung stellt. XKMS besteht aus zwei Teilen: X- KISS (XML Key Information Service Specification) definiert, wie die Schlüssel gesucht, bezogen und validiert werden, und X-KRSS (XML Key Registration Service Specification) spezifiziert, wie die Schlüssel per Service registriert werden. Wie gesagt, werden ohne XMKS die Schlüssel gerne im Dateisystem verstreut abgelegt und sind somit kaum administrierbar. Zur Verdeutlichung der Sicherheitsmechanismen soll auch hier als Beispiel unsere virtuelle Autovermietung RYLC dienen [5]. Der zu sichernde Bestellprozess Das RYLC-Management hat zusammen mit den Chefarchitekten beschlossen, zukünftig den Bestellprozess SOA-fiziert wie folgt umzusetzen: Der Sachbearbeiter oder Kunde meldet sich am Webportal an und lässt sich die Leistungen und Preise jeder Autokategorie auflisten. Bei einer Reservierung wird der abgesicherte Service Angebot erstellen aufgerufen, der intern wiederum die abgesicherten Services Firmenrabatt ermitteln und Kundenstatus ermitteln, zur Berechnung der Konditionen, aufruft. Zudem wird die Verfügbarkeit des Autos am Standort durch den Aufruf des Service Verfügbarkeit prüfen der entfernten RentalApplication im Hintergrund ermittelt. Als Antwort erhält der Kunde ein Angebot mit Auflistung der Leistungen, des Preises und die möglichen Optionen der Versicherungsleistungen. Das Angebot der Versicherung wird jedoch nicht firmenintern, sondern durch Aufruf des extern abgesicherten Services Prämienberechnung für Mietauto aller Versicherungspartner ermittelt. Als Regel gilt derzeit, dass die günstigste Variante mit in das Angebot übernommen wird. Nimmt der Kunde das Angebot wahr Aufruf des Service Auftrag erteilen wird anhand Sicherheitsherausforderungen Der Chefarchitekt ist mit einer ganzen Menge von Sicherheitsanforderungen konfrontiert. Der Prozess muss abgesicherte Services der verschiedensten Applikationen integrieren. Externe Aufrufe gehen über das Internet und müssen somit auf Protokollebene abgesichert werden. Bei der Bonitätsanfrage wird neben der Verschlüsselung eine Signatur der Nachricht vom Anbieter verlangt. Abhängig von der Anwenderrolle (Großkunde, Endkunde) sind dem Anwender unterschiedliche Daten zu liefern. Und zuletzt sind aus Compliance-Anforderungen heraus alle verändernden Zugriffe zu protokollieren. Bedenkt man, dass Sicherheitsanforderungen in herkömmlichen Systemen durch ihre lokale Beschränkung meist relativ einfach beherrschbar sind, ändert sich dies bei übergreifender Prozessorientierung. Es werden nun nicht mehr nur lokale und ineinandergreifende Authentifizierungsmechanismen gefordert, sondern abhängig vom Aufrufkontext werden pro Service unterschiedliche Authentifizierungsmechanismen, die im Hintergrund zusammenarbeiten müssen, gefordert. Services, die von einem Host-System oder einer PL/SQL- Datenbank angeboten werden, verwalten ihre Benutzer mit unterschiedlichen Anmeldenamen meist intern. Diese Services müssen bei End2End-Sicherheitsanforderungen nun zusammenarbeiten. SOA macht im Bezug auf Security die IT-Landschaften von RYLC also nicht einfacher, sondern durch die Verzahnung eher komplexer: Was nützt jedoch die beste Sicherheit, wenn die Systeme und Produkte die IT-Sicherheitsstandards nur rudimentär implementieren und durch die Vielzahl der Standards selbst Experten Mühe haben, eine tragfähige und vor allem übergreifend wir- 88 javamagazin

8 SOA aus dem wahren Leben Teil 8 SOA Center Abb. 2: RYLC-Sicherheitsarchitektur kende Sicherheitsarchitektur aufzubauen. Wir gehen deshalb im Folgenden auf die Implementierung der Sicherheit in unserer Autovermietung näher ein. Authentifizierung über SSO-WebGate Der Sachbearbeiter meldet sich über das Webportal an. Dafür wurde die bestehende anwendungslokale Login- Maske entfernt und auf ein SSO-Login- Verfahren umgestellt, um im Weiteren eine identitätsübergreifende Sicherheit mit SAML implementieren zu können. Technologisch mussten dazu die lokal in einer DB-Tabelle vorgehaltenen Identitäten harmonisiert werden, mit dem Ziel, nur noch eine Identität pro Anwender vorzuhalten und nicht mehr eine pro Anwendung. Diese Identität wird in einem LDAP-Verzeichnis abgelegt. Vor das Webportal stellt der Chefarchitekt ein SSO-WebGate als eigenständige Komponente außerhalb des Applikationsservers. Dieses soll alle Requests abfangen, die enthaltenen Credentials validieren und wenn nötig ein SSO-Token über einen zentralen Authentifizierungsdienst erstellen. Der Authentifizierungsdienst, der heute meist als Access Manager bezeichnet wird, greift zur Validierung auf die hinterlegte Identität im LDAP-Verzeichnis zurück. Moderne Authentifizierungsdienste verwenden ein SAML-Token, um damit einen Java- EE-Sicherheitskontext aufzubauen. Dazu ist das JAAS-Login-Modul im Applikationsserver zu konfigurieren, das das SSO-Token erkennt, revalidiert und den Java-EE-Sicherheitskontext mit allen Rollen und Principals aufbaut. Warum entscheidet sich der Chefarchitekt für den Umweg über das Web Gateway und den Access Manager und verwendet nicht die im Applikationsserver integrierte Java-EE-Authentifizierung allein? SSO ist derzeit nicht standardisiert und SAML2 für Web-SSO noch kaum verbreitet. Würden alle Systemkomponenten direkt auf ein LDAP zugreifen, wäre meist nur eine User/ Passwort- und kaum eine andere Form der Authentifizierung möglich, was ein Übertragen des Sicherheitskontextes unmöglich machen würde. Zudem wären der Administrationsaufwand und die Verwaltung aller Zugriffs-Policies um ein Vielfaches aufwändiger als über eine Policy-Management-Komponente. Auch beliebige Clients können problem- los an die separate Authentifizierungskomponente angebunden werden. Weitergeben der ID in Serviceketten Nach erfolgreichem SSO-Login wird ein BPEL-Prozess gestartet, der wiederum die intern abgesicherten Web Services wie z. B. Angebot erstellen aufruft. Da die initiierende Anwendung, die Java-EE- Portalanwendung, die den Geschäftsprozess startet, aus dem Java-EE-Container kein Password ermitteln kann, muss das im Applikationsserver abgelegte SSO- Token (idealerweise SAML2-Token) in den SOAP Header des BPEL-Aufrufs gelegt und von den Folgeservices verstanden werden. Natürlich soll diese Querschnittsaufgabe nicht vom Programmierer selbst übernommen werden; vielmehr verwendet der Chefarchitekt dazu ein Policy-Framework, das alle Querschnittsaufgaben über den im Web Service verankerten Agenten (PEP Policy Enforcement Point) automatisiert erledigt. In unserem Fall ermittelt der Agent das Token aus dem Java EE Subject und erzeugt vor dem Versenden einen WS-Security-Eintrag im SOAP Header. Die einzige Aufgabe des Entwicklers/Deployers ist javamagazin

9 SOA Center SOA aus dem wahren Leben Teil 8 dann das Konfigurieren des Applikationsservers mit dem JAAS-Login-Modul, das aus dem SSO-Ticket den Java EE Security Context erstellt, und das Einbinden des Agenten beim Deployment des Web Services. Weitergabe an externe Services Neben den lokalen werden noch externe Web Services wie Verfügbarkeit prüfen oder Bonität prüfen angesprochen. Wie kann der Sicherheitskontext zu diesen externen Services übertragen werden, wenn man davon ausgehen kann, dass der externe Kreditkartendienstleister nicht alle potenziellen Aufrufidentitäten anlegen und verwalten will? Ein hier üblicher Weg ist, dass der Web-Service-Provider dem bereits validierten Sicherheits-Token (SAML) eines zuvor konfigurierten Ausstellers vertraut und nur noch die Integrität des Tokens prüft. Dazu muss das Zertifikat mit im übertragenen Sicherheitskontext enthalten sein. Beim Aufruf externer Services werden auch sensible Daten wie z. B. die Kreditkartennummer übermittelt, weshalb der Chefarchitekt die verlangte Vertraulichkeit mit in die Absicherung integrieren muss. Die Überlegung, Verschlüsselung der Daten allein auf Protokollebene per SSL zu realisieren, scheidet aus, da damit die geforderte End2End-Vertraulichkeit nicht realisierbar wäre. Also wird nicht nur der Weg, sondern auch die Nachricht verschlüsselt und ein Siegel mit dem privaten Schlüssel darauf gesetzt. Verwendet wird dazu das im WS-Security-Standard verankerte RSA-Verfahren, bei dem mit dem öffentlichen Schlüssel des Providers die Nachricht verschlüsselt wird. Entschlüsseln kann nun nur der Besitzer mit dem vorhanden privaten Schlüssel. Da in unserem Fall die Web Services bereits mit einem Agenten (PEP) bestückt sind, wird über das Policy-Management-Frontend die Policy zum Verschlüsseln der Nachricht zusätzlich angelegt. Beim Aufruf des Services durchläuft der Web Service alle für den PEP konfigurierten Policies (Insert Security Token, Encrypt, Sign) und führt diese sequenziell aus, wie in der Pipeline hinterlegt. Es ist fatal, Sicherheit auf die leichte Schulter zu nehmen und naiv zu implementieren. Nun ist die gesamte Nachricht verschlüsselt. Dies führt jedoch dazu, dass der ESB und die BPEL-Prozesse keine Routing-Logik mehr nutzen können, um die Nachricht an den korrekten Kreditkartenprovider zu senden. Also entschließt sich der Chefarchitekt zu einer Teilverschlüsselung, etwa nur noch der Kreditkartennummer und des Betrags. Die für das Routing nötigen Informationen werden nicht mehr verschlüsselt. Dies ist mit dem Policy-Framework, im Gegensatz zu JAX-WS, einfach zu lösen. Als weiterer Schutz wird nun die schon verschlüsselte Nachricht noch über einen VPN-Tunnel oder alternativ per SSL zum Kunden übertragen. Fazit Wir haben beschrieben, welche Sicherheitslösungen es für Verfügbarkeit, Vertraulichkeit, Integrität und Authentizität gibt. Die Lösungen sollten auf das Risiko, das sie adressieren, abgebildet sein: Mit Sicherheitslösungen gehen erhöhte Komplexität und tendenzielle Verschlechterung der Performance einher auf diesen Aspekt weisen wir hier hin und beleuchten ihn nicht näher im Artikel. Wohl wissend, dass ohne Security-Federation, Identity-Management (IdM) und Trust-Server eine übergreifende Sicherheit schwer realisierbar ist, haben wir uns im Artikel nur auf die häufig gegebenen Problemstellungen konzentriert. Es ist wichtig, die Security-Aspekte im Team und im Quellcode strikt zu isolieren. Es ist fatal, Sicherheit auf die leichte Schulter zu nehmen und naiv zu implementieren, etwa mit Benutzername/ Passwort-Paaren, die in allen Services weitergereicht werden. Wir haben gesehen, wie sich die Komplexität einer Security-Architektur als Sicherheitsaspekt außerhalb der Serviceimplementierung mithilfe von Policies isolieren und gut bewältigen lässt. Die Autoren: 2007 gründeten die Autoren die Masons-of-SOA mit der Vision, SOA über internationale Unternehmensgrenzen hinweg zu propagieren, kritische Projekte gemeinsam zu unterstützen und Erfahrung aus zusammen 20 SOA-Projektjahren weiterzugeben. Die Publikation dreier Entwurfsmuster (Compensating Service Transaction, UI Mediator sowie Canonical Schema Bus) in Thomas Erls SOA-Design-Patterns-Buch und die vorliegende Artikelserie sind Beispiele für diese Arbeit. Links & Literatur [1] IT-Grundschutz-Zertifikat: [2] verfuegbarkeit-integritaet-vertraulichkeit-authentizitaet [3] [4] [5] Berthold Maier, Hajo Normann, Bernd Trops, Clemens Utschig-Utschig, Torsten Winterberg: Rent your Car Service-oriented, Java Magazin [6] building.htm#bcghjhed [7] SAML OASIS: oasis-wss-saml-token-profile-1.0.pdf [8] [9] [10] 90 javamagazin

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

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

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

Nutzung und Erweiterung von IT-Standards zur Realisierung von Authentifizierung und Zugriffsschutz für Geo Web Services

Nutzung und Erweiterung von IT-Standards zur Realisierung von Authentifizierung und Zugriffsschutz für Geo Web Services Nutzung und Erweiterung von IT-Standards zur Realisierung von Authentifizierung und Zugriffsschutz für Geo Web Services Universität der Bundeswehr München Was erwartet Sie in diesem Vortrag? Thema 4 Thema

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

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

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

Identity Propagation in Fusion Middleware

Identity Propagation in Fusion Middleware Identity Propagation in Fusion Middleware Klaus Scherbach Oracle Deutschland B.V. & Co. KG Hamborner Str. 51, 40472 Düsseldorf Schlüsselworte Oracle Fusion Middleware, Oracle Access Management, Identity

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

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

Seminar Grid-Computing. Oktay Tugan, WS 2006/07 SICHERHEIT

Seminar Grid-Computing. Oktay Tugan, WS 2006/07 SICHERHEIT Seminar Grid-Computing Oktay Tugan, WS 2006/07 SICHERHEIT Überblick Motivation Sicherheitsfunktionen und Schwierigkeiten Anforderungen Beispiel GSI Weitere Sicherheitsmechanismen Gesellschaftliche Probleme

Mehr

Projekt Smart Web Grid

Projekt Smart Web Grid Projekt Smart Web Grid Eine übergreifende Smart Grid Informationsplattform für alle Teilnehmer Thomas Leber Institut für Computertechnik: Energy&IT Research 17. Juni, Wien Computer Technology /12 Das Smart

Mehr

SOA secure Sicherheitsaspekte Serviceorientierter Architekturen

SOA secure Sicherheitsaspekte Serviceorientierter Architekturen CM Network e.v. 7. Symposium: IT-Sicherheit SOA secure Sicherheitsaspekte Serviceorientierter Architekturen Dipl.-Wirtsch.-Inf. Stefan Krecher stefan@krecher.com Übersicht Service Orientierte Architekturen

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

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

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

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

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

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

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

Sicherheitstechnische Qualifizierung (SQ), Version 10.0 Security Assurance Level SEAL-3

Sicherheitstechnische Qualifizierung (SQ), Version 10.0 Security Assurance Level SEAL-3 Die Zertifizierungsstelle der TÜV Informationstechnik GmbH bescheinigt hiermit dem Unternehmen RWE Effizienz GmbH Flamingoweg 1 44139 Dortmund für das IT-System RWE eoperate IT Services die Erfüllung aller

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

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

Leistung schafft Vertrauen

Leistung schafft Vertrauen SOA Hintergrund und Praxis visionäre Praxis oder praxisnahe Vision Toni Gasser Integration Services 27. Oktober 2010 Leistung schafft Vertrauen Private Banking Investment Banking Asset Management Seite

Mehr

Vertrauenswürdige Identitäten für die Cloud

Vertrauenswürdige Identitäten für die Cloud Vertrauenswürdige Identitäten für die Cloud Anforderungen und Lösungsansätze für das Identitätsmanagement in private Clouds am Beispiel des goberlin-projektes Florian Thiemer 9. September 2013 goberlin

Mehr

Identity Management mit OpenID

Identity Management mit OpenID Lehrstuhl Netzarchitekturen und Netzdienste Institut für Informatik Technische Universität München Identity Management mit OpenID Innovative Internet Technologien und Mobilkommunikation WS2008/2009 Verfasser:

Mehr

HP OpenView Select Access

HP OpenView Select Access U. Könenberg, F. Waibel, C. Ziegler Veranstaltung, SS05 Prof. Dr. Martin Leischner 1 Gliederung 1. Einordnung Select Access 2. Funktionen von Select Access 3. Systemarchitektur 4. Administration 5. Ablauf

Mehr

Sicherheit in Workflow-Management-Systemen

Sicherheit in Workflow-Management-Systemen Sicherheit in Workflow-Management-Systemen Fakultät für Informatik Institut für Programmstrukturen und Datenorganisation KIT University of the State of Baden-Wuerttemberg and National Research Center of

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

Web Services. 1. Quelle. Brian Connel The Seven Pillars of Web Services Management. Erschienen September 2002 im eai Journal

Web Services. 1. Quelle. Brian Connel The Seven Pillars of Web Services Management. Erschienen September 2002 im eai Journal Web Services - Brian Connel: The Seven Pillars of Web Services Management - IBM: IBM Strategy for management of the WebServices infrastrucutre Seminarvortrag von Lukasz Kidawski im Rahmen der Lehrveranstaltung

Mehr

WSO2 Middleware Platform Vorlesungsbegleitendes Praktikum soa

WSO2 Middleware Platform Vorlesungsbegleitendes Praktikum soa WSO2 Middleware Platform Vorlesungsbegleitendes Praktikum soa Dr. Stefan Pietschmann, PF Service-Oriented Enterprise Applications, T-Systems MMS Dresden, 22.10.2013 About US PF42 Service-oriented enterprise

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

DFN-AAI Sicherheitsaspekte und rechtliche Fragen

DFN-AAI Sicherheitsaspekte und rechtliche Fragen DFN-AAI Sicherheitsaspekte und rechtliche Fragen Ulrich Kähler, DFN-Verein kaehler@dfn.de Seite 1 Gliederung Sicherheitsaspekte Rechtliche Fragen Seite 2 Sicherheit Die Sicherheit in der DFN-AAI ist eine

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

securemsp CloudShare Encrypted File Transfer & Collaboration Platform Secure-MSP GmbH 2013

securemsp CloudShare Encrypted File Transfer & Collaboration Platform Secure-MSP GmbH 2013 securemsp CloudShare Encrypted File Transfer & Collaboration Platform Secure-MSP GmbH 2013 Häufig gestellte Fragen... Wie geben wir unseren Zweigstellen Zugang zu sensiblen Daten? Wie komme ich unterwegs

Mehr

Metadata Service Respository (MDS) - Sehen, lernen, verstehen!

Metadata Service Respository (MDS) - Sehen, lernen, verstehen! Metadata Service Respository (MDS) - Sehen, lernen, verstehen! Carsten Wiesbaum esentri AG Schlüsselworte Metadata Service Repository, MDS, Oracle Fusion Middleware Einleitung Früher oder später wird jeder

Mehr

E-Mail Verschlüsselung

E-Mail Verschlüsselung E-Mail Verschlüsselung S/MIME Standard Disclaimer: In der Regel lässt sich die Verschlüsselungsfunktion störungsfrei in den E-Mail-Programmen einrichten. Es wird aber darauf hingewiesen, dass in einigen

Mehr

Anwendungsintegration an Hochschulen am Beispiel von Identity Management. Norbert Weinberger - Sun Summit Bonn 26.4.2006

Anwendungsintegration an Hochschulen am Beispiel von Identity Management. Norbert Weinberger - Sun Summit Bonn 26.4.2006 Anwendungsintegration an Hochschulen am Beispiel von Identity Management Norbert Weinberger - Sun Summit Bonn 26.4.2006 Ausgangslage: Anwendungsinseln Zugang zu IT- Ressourcen, z.b. Radius Rechenzentrum

Mehr

Active Repository und Active Migration Manager

Active Repository und Active Migration Manager Mit der neuen Active Outlook App lassen sich Emails direkt aus Outlook 2013 oder aus Outlook 2013 WebApp archivieren oder auf Storagesysteme auslagern! An Funktionalitäten sind die Archivierung und Auslagerung

Mehr

Secure Socket Layer (SSL) - Zertifikate

Secure Socket Layer (SSL) - Zertifikate e Einführung Zur Übertragung sensibler Daten über das Internet wurde das SSL-Protokoll entwickelt. SSL steht für Secure Socket Layer (dt. "sichere Sockelschicht") das von der Firma Netscape und RSA Data

Mehr

IHE Cookbook Grundlage für einrichtungsübergreifende Patienten- und Fallakten auf Basis internationaler Standards

IHE Cookbook Grundlage für einrichtungsübergreifende Patienten- und Fallakten auf Basis internationaler Standards IHE Cookbook Grundlage für einrichtungsübergreifende Patienten- und Fallakten auf Basis internationaler Standards Dr. Ralf Brandner, ICW AG Agenda 1. Einleitung 2. Rechtliche und Technische Rahmenbedingungen

Mehr

PL/SQL Web-Services mit Oracle 11g

PL/SQL Web-Services mit Oracle 11g DOAG 2008 Konferenz 01. - 03.12.2008 Nürnberg Markus Fiegler ORDIX AG, Paderborn mf@ordix.de www.ordix.de Agenda SOA und Web-Services im Überblick Datenbank als Web-Services Provider - Alternative mit

Mehr

Seminarvortrag Serviceorientierte Softwarearchitekturen

Seminarvortrag Serviceorientierte Softwarearchitekturen Seminarvortrag Serviceorientierte Softwarearchitekturen vorhandene Altsysteme Gliederung Einführung Grundlegende Modelle Grundlegende Komponenten Architekturen 2 Einführung Altanwendung und Altsysteme?

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

B2B für meine Geschäftspartner

B2B für meine Geschäftspartner B2B für meine Geschäftspartner Michael Stapf Oracle Deutschland B.V. & Co. KG Frankfurt Schlüsselworte B2B, Business-to-Business, Geschäftspartnerintegration, Elektronische Geschäftskommunikation Einleitung

Mehr

Betriebssysteme und Sicherheit Sicherheit. Signaturen, Zertifikate, Sichere E-Mail

Betriebssysteme und Sicherheit Sicherheit. Signaturen, Zertifikate, Sichere E-Mail Betriebssysteme und Sicherheit Sicherheit Signaturen, Zertifikate, Sichere E-Mail Frage Public-Key Verschlüsselung stellt Vertraulichkeit sicher Kann man auch Integrität und Authentizität mit Public-Key

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

(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

Client/Server-Systeme

Client/Server-Systeme Frühjahrsemester 2011 CS104 Programmieren II / CS108 Programmier-Projekt Java-Projekt Kapitel 3: /Server-Architekturen H. Schuldt /Server-Systeme Ein zweischichtiges /Server-System ist die einfachste Variante

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

Trusted Network Connect

Trusted Network Connect Trusted Network Connect Workshoptag 22.11.2007 Steffen Bartsch Stephan Gitz Roadmap Ziele der Informationssicherheit Herausforderungen der Informationssicherheit

Mehr

Sicherheitstechnische Qualifizierung (SQ), Version 10.0 Security Assurance Level SEAL-3

Sicherheitstechnische Qualifizierung (SQ), Version 10.0 Security Assurance Level SEAL-3 Die Zertifizierungsstelle der TÜV Informationstechnik GmbH bescheinigt hiermit dem Unternehmen Agfa HealthCare GmbH Konrad-Zuse-Platz 1-3 53227 Bonn für das IT-System IMPAX/web.Access die Erfüllung aller

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

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

Studentenzertifikate für Online-Dienste der Hochschule Landshut

Studentenzertifikate für Online-Dienste der Hochschule Landshut Studentenzertifikate für Online-Dienste der Hochschule Landshut Entstanden aus einem Studienprojekt des Fachbereichs Informatik Start Sommersemester 2001 Ziel: CA für FH-Server, Mitarbeiter und Studenten

Mehr

Infrastruktur: Vertrauen herstellen, Zertifikate finden

Infrastruktur: Vertrauen herstellen, Zertifikate finden TeleTrusT Bundesverband IT-Sicherheit e.v. Infrastruktur: Vertrauen herstellen, Zertifikate finden Allgemeines zur TeleTrusT EBCA Seit 2001 Zusammenschluss einzelner, gleichberechtigter n zu -Verbund einfacher,

Mehr

Trusted Network Connect. Networking Academy Day 19.04.2008

Trusted Network Connect. Networking Academy Day 19.04.2008 Trusted Network Connect Networking Academy Day 19.04.2008 Dipl.-Inf. Stephan Gitz Roadmap Ziele der Informationssicherheit Herausforderungen der Informationssicherheit Angriffsvektoren

Mehr

Kryptographie oder Verschlüsselungstechniken

Kryptographie oder Verschlüsselungstechniken Kryptographie oder Verschlüsselungstechniken Dortmund, Dezember 1999 Prof. Dr. Heinz-Michael Winkels, Fachbereich Wirtschaft FH Dortmund Emil-Figge-Str. 44, D44227-Dortmund, TEL.: (0231)755-4966, FAX:

Mehr

Inhalt. Vorwort 13. L.., ',...":%: " j.

Inhalt. Vorwort 13. L.., ',...:%:  j. Inhalt Vorwort 13 L.., ',...":%: " j. 1. '-.:. ' " '.!. \, : - '. - * T '. ; - J A '.. ' I '",. - ' :'. ",..! :'. " ','. '.. ' t i ' ~ J \ I -.. I. j ' - ' V "!» " J f i " 1 1 * V. " ^ ' ' ' -.» ; ' ',

Mehr

Sichere E-Mail für Rechtsanwälte & Notare

Sichere E-Mail für Rechtsanwälte & Notare Die Technik verwendet die schon vorhandene Technik. Sie als Administrator müssen in der Regel keine neue Software und auch keine zusätzliche Hardware implementieren. Das bedeutet für Sie als Administrator

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

Whitepaper. bi-cube SSO SSO in einer Terminal Umgebung. T e c h n o l o g i e n L ö s u n g e n T r e n d s E r f a h r u n g

Whitepaper. bi-cube SSO SSO in einer Terminal Umgebung. T e c h n o l o g i e n L ö s u n g e n T r e n d s E r f a h r u n g Whitepaper bi-cube SSO T e c h n o l o g i e n L ö s u n g e n T r e n d s E r f a h r u n g Inhalt 1 DIE SITUATION...3 2 ZIELSTELLUNG...4 3 VORAUSSETZUNG...5 4 ARCHITEKTUR DER LÖSUNG...6 4.1 Biometrische

Mehr

NetScaler Integration bei Hellmann Worldwide Logistics. Benjamin Kania IS Enterprise Services Manager Hannover, 13.10.2011

NetScaler Integration bei Hellmann Worldwide Logistics. Benjamin Kania IS Enterprise Services Manager Hannover, 13.10.2011 NetScaler Integration bei Hellmann Worldwide Logistics Benjamin Kania IS Enterprise Services Manager Hannover, 13.10.2011 Agenda Firmenporträt Das Projekt Details zur Umsetzung Fazit Fakten & Zahlen Mitarbeiter

Mehr

10. Seminar GIS & INTERNET, 11. Sept. 2007

10. Seminar GIS & INTERNET, 11. Sept. 2007 Service-orientierte Architektur (SOA) und Geodateninfrastruktur (GDI): dienstbare GIS-Komponenten Dr.-Ing. Jens Hartmann, Account Manager 10. Seminar GIS & INTERNET, 11. Sept. 2007 Agenda Motivation Service-orientierte

Mehr

ARTS Server 3.5. Produktbeschreibung. Uptime Services AG

ARTS Server 3.5. Produktbeschreibung. Uptime Services AG Uptime Services AG Brauerstrasse 4 CH-8004 Zürich Tel. +41 44 560 76 00 Fax +41 44 560 76 01 www.uptime.ch ARTS Server 3.5 Produktbeschreibung Uptime Services AG Inhaltsverzeichnis 1 Einleitung... 2 2

Mehr

Endpoint Security. Where trust begins and ends. SINN GmbH Andreas Fleischmann Technischer Leiter. www.s-inn.de

Endpoint Security. Where trust begins and ends. SINN GmbH Andreas Fleischmann Technischer Leiter. www.s-inn.de Endpoint Security Where trust begins and ends SINN GmbH Andreas Fleischmann Technischer Leiter www.s-inn.de Herausforderung für die IT Wer befindet sich im Netzwerk? Welcher Benutzer? Mit welchem Gerät?

Mehr

Geschäftsprozessimplementierung mit BPMN, ADF und WebCenter

Geschäftsprozessimplementierung mit BPMN, ADF und WebCenter Geschäftsprozessimplementierung mit BPMN, ADF und WebCenter Johannes Michler PROMATIS software GmbH Ettlingen Schlüsselworte Geschäftsprozess, Horus, SOA, BPMN, ADF, WebCenter Einleitung Die Umsetzung

Mehr

Fragen und Antworten zu Secure E-Mail

Fragen und Antworten zu Secure E-Mail Fragen und Antworten zu Secure E-Mail Inhalt Secure E-Mail Sinn und Zweck Was ist Secure E-Mail? Warum führt die Suva Secure E-Mail ein? Welche E-Mails sollten verschlüsselt gesendet werden? Wie grenzt

Mehr

Vorwort E-Mail ist heute für Unternehmen ein häufig eingesetztes Kommunikationsmittel, das zum Austausch von Informationen verwendet wird.

Vorwort E-Mail ist heute für Unternehmen ein häufig eingesetztes Kommunikationsmittel, das zum Austausch von Informationen verwendet wird. Vorwort E-Mail ist heute für Unternehmen ein häufig eingesetztes Kommunikationsmittel, das zum Austausch von Informationen verwendet wird. Auch die Unternehmensgruppe ALDI Nord steht mit einer Vielzahl

Mehr

E-Mail-Verschlüsselung Vorrausetzungen

E-Mail-Verschlüsselung Vorrausetzungen E-Mail-Verschlüsselung Vorrausetzungen Datum: 09.08.2011 Dokumentenart: Anwenderbeschreibung Version: 2.0 : Redaktionsteam PKI cio.siemens.com Inhaltsverzeichnis 1. Zweck des Dokumentes:...3 2. Voraussetzungen...4

Mehr

OTRS-TFS-Konnektor. Whitepaper. Autor: advanto Software GmbH Mittelstraße 10 39114 Magdeburg

OTRS-TFS-Konnektor. Whitepaper. Autor: advanto Software GmbH Mittelstraße 10 39114 Magdeburg OTRS-TFS-Konnektor Whitepaper Autor: advanto Software GmbH Mittelstraße 10 39114 Magdeburg Tel: 0391 59801-0 Fax: 0391 59801-10 info@advanto-software.de Stand: Mai 2015 Inhaltsverzeichnis 1 Idee... 3 2

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

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

Ora Education GmbH. Lehrgang: Oracle Application Server 10g R2: Administration I

Ora Education GmbH. Lehrgang: Oracle Application Server 10g R2: Administration I Ora Education GmbH www.oraeducation.de info@oraeducation.de Lehrgang: Oracle Application Server 10g R2: Administration I Beschreibung: Der Teilnehmer ist in der Lage den Oracle Application Server 10g zu

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

Single Sign-On Step 1

Single Sign-On Step 1 Single Sign-On Step 1 Novell Tour 2006 Stefan Stiehl Senior Technology Specialist sstiehl@novell.com Holger Dopp Senior Consultant hdopp@novell.com Was ist Single Sign-On? Eine Befugnisverwaltungstechnologie,

Mehr

ISA Server 2004 Site to Site VPN mit L2TP/IPSEC - Von Marc Grote

ISA Server 2004 Site to Site VPN mit L2TP/IPSEC - Von Marc Grote ISA Server 2004 Site to Site VPN mit L2TP/IPSEC - Von Marc Grote Die Informationen in diesem Artikel beziehen sich auf:? Microsoft ISA Server 2004 Einleitung Dieser Artikel beschreibt die Einrichtung eines

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

Enterprise User Security mit Active Directory

Enterprise User Security mit Active Directory Enterprise User Security mit Active Directory Jürgen Kühn Trivadis GmbH Düsseldorf Schlüsselworte: Enterprise User Security, Active Directory, Directory Integration and Provisioning, Active Directory Passwort

Mehr

Single Sign On mit Forms direkt gegen ein Active Directory

Single Sign On mit Forms direkt gegen ein Active Directory Single Sign On mit Forms direkt gegen ein Active Directory Wolf G. Beckmann TEAM GmbH Paderborn Schlüsselworte Forms, SSO, Kerberos Einleitung Sicherheit ist zurzeit ein hochaktuelles Thema und gerät deshalb

Mehr

SOA Security in der Praxis Entwurfsmuster für eine sichere Umsetzung

SOA Security in der Praxis Entwurfsmuster für eine sichere Umsetzung Ergebnisse der TeleTrusT-AG "SOA" SOA Security in der Praxis Entwurfsmuster für eine sichere Umsetzung Arbeitsergebnisse des SOA Security AKs Anfang 2009 - Themenfindung für das Dokument Mitte 2009 Vorgehenskonzept

Mehr

DNSSEC. Was ist DNSSEC? Wieso braucht man DNSSEC? Für ein sicheres Internet

DNSSEC. Was ist DNSSEC? Wieso braucht man DNSSEC? Für ein sicheres Internet SEC Für ein sicheres Internet Was ist SEC? SEC ist eine Erweiterung des Domain Namen Systems (), die dazu dient, die Echtheit (Authentizität) und die Voll ständig keit (Integrität) der Daten von - Antworten

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

Stephan Groth (Bereichsleiter IT-Security) 03.05.2007. CIO Solutions. Zentrale E-Mail-Verschlüsselung und Signatur

Stephan Groth (Bereichsleiter IT-Security) 03.05.2007. CIO Solutions. Zentrale E-Mail-Verschlüsselung und Signatur Stephan Groth (Bereichsleiter IT-Security) 03.05.2007 CIO Solutions Zentrale E-Mail-Verschlüsselung und Signatur 2 Wir stellen uns vor Gegründet 2002 Sitz in Berlin und Frankfurt a. M. Beratung, Entwicklung

Mehr

Sicherheit in Enterprise-Netzen durch den Einsatz von 802.1X

Sicherheit in Enterprise-Netzen durch den Einsatz von 802.1X Sicherheit in Enterprise-Netzen durch den Einsatz von 802.1X von Cornelius Höchel-Winter Technologie Report: Sicherheit in Enterprise-Netzen durch 802.1X Seite 4-76 4 Produkte und Methoden: Kriterien zur

Mehr

12.4 Sicherheitsarchitektur

12.4 Sicherheitsarchitektur 12.4 Sicherheitsarchitektur Modellierung Sicherheitsstrategie Systemmodell Sicherheitsmodell Entwurf Architektur Sicherheitsarchitektur Implementierung sicherer Code SS-12 1 Wie wird das Sicherheitsmodell

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

So gelingt die sichere Kommunikation mit jedem Empfänger. E-Mail-Verschlüsselung ist kein Hexenwerk

So gelingt die sichere Kommunikation mit jedem Empfänger. E-Mail-Verschlüsselung ist kein Hexenwerk So gelingt die sichere Kommunikation mit jedem Empfänger Andreas Richter EVP Marketing & Product Management GROUP Business Software AG E-Mail-Verschlüsselung ist kein Hexenwerk Datenschutz im Fokus der

Mehr

Signierung und Verschlüsselung von E-Mails mit einem S/MIME Zertifikat

Signierung und Verschlüsselung von E-Mails mit einem S/MIME Zertifikat Signierung und Verschlüsselung von E-Mails mit einem S/MIME Zertifikat S/MIME steht für Secure / Multipurpose Internet Mail Extensions und ist ein Standard für die Signierung und Verschlüsselung von E-Mails.

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

Sichere Web-Services in einem föderierten Umfeld

Sichere Web-Services in einem föderierten Umfeld Sichere Web-Services in einem föderierten Umfeld ZKI Arbeitskreis Verzeichnisdienste ZEDAT FU Berlin Axel Maurer Die Kooperation von Forschungszentrum Karlsruhe GmbH und Universität Karlsruhe (TH) integrierte

Mehr

Sicherheitstechnische Qualifizierung (SQ), Version 10.0 Security Assurance Level SEAL-5

Sicherheitstechnische Qualifizierung (SQ), Version 10.0 Security Assurance Level SEAL-5 Die Zertifizierungsstelle der TÜV Informationstechnik GmbH bescheinigt hiermit dem Unternehmen SLA Software Logistik Artland GmbH Friedrichstraße 30 49610 Quakenbrück für das IT-System Meat Integrity Solution

Mehr

Dominik Helleberg inovex GmbH. Android-Enterprise- Integration

Dominik Helleberg inovex GmbH. Android-Enterprise- Integration Dominik Helleberg inovex GmbH Android-Enterprise- Integration Dominik Helleberg Mobile Development Android HTML5 http://dominik-helleberg.de/+ http://twitter.com/_cirrus_ Agenda Intro Enterprise Apps /

Mehr

mitho -Framework für plenty PHP-Framework zur Anbindung an die plenty API

mitho -Framework für plenty PHP-Framework zur Anbindung an die plenty API PHP-Framework zur Anbindung an die plenty API Inhaltsverzeichnis 1 Kurzbeschreibung...3 2 Integration...4 3 Möglichkeiten...5 3.1 Artikel...5 3.2 Aufträge...5 3.3 Kunden...5 4 Interne Funktionsweise...7

Mehr

Error-Hospital für Oracle SOA Suite

Error-Hospital für Oracle SOA Suite Error-Hospital für Oracle SOA Suite Markus Lohn esentri AG Ettlingen Schlüsselworte Fusion Middleware, SOA, SOA Suite Einleitung Die Entwicklung von Services mit der SOA Suite erfolgt überwiegend deklarativ

Mehr

Wie wird nun aus einem Zertifikat eine Signatur?

Wie wird nun aus einem Zertifikat eine Signatur? DIGITALE SIGNATUR IN DER PRAXIS ODER WIE WIRD AUS EINEM ZERTIFIKAT EINE (SICHERE) SIGNATUR? Der folgende Beitrag befaßt sich besonders mit dem Zusammenspiel von Zertifizierungsdiensteanbieter (ZDA) einerseits

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

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