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

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

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

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

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

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

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

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

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

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

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

(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

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

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

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

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

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

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

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

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

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

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

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

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

Prinzipiell wird bei IP-basierenden VPNs zwischen zwei unterschiedlichen Ansätzen unterschieden:

Prinzipiell wird bei IP-basierenden VPNs zwischen zwei unterschiedlichen Ansätzen unterschieden: Abkürzung für "Virtual Private Network" ein VPN ist ein Netzwerk bestehend aus virtuellen Verbindungen (z.b. Internet), über die nicht öffentliche bzw. firmeninterne Daten sicher übertragen werden. Die

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

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

Identity and Access Management for Complex Research Data Workflows

Identity and Access Management for Complex Research Data Workflows Identity and Access Management for Complex Research Data Workflows Richard Zahoransky, Saher Semaan, Klaus Rechert richard.zahoransky@rz.uni-freiburg.de, semaan@uni-freiburg.de, klaus.rechert@rz.uni-freiburg.de

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

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

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

ITSM Infoday 2013. Mit Business Process Service Management zu mehr Flexibilität, Transparenz und Stabilität. Peter Brückler

ITSM Infoday 2013. Mit Business Process Service Management zu mehr Flexibilität, Transparenz und Stabilität. Peter Brückler ITSM Infoday 2013 Mit Business Process Management zu mehr Flexibilität, Transparenz und Stabilität Peter Brückler Copyright 2013 NTT DATA EMEA Ltd. Agenda Der Druck auf Unternehmen Business Process Management

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

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

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

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

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

S Sparkasse. UnnaKamen. Secure Mail Notwendigkeit?

S Sparkasse. UnnaKamen. Secure Mail Notwendigkeit? S Sparkasse UnnaKamen Secure Mail Notwendigkeit? Das sogenannte Sniffen, Ausspähen von E-Mailinhalten und Authentifizierungsdateien sowie das E-Mail Spoofing, das Erstellen einer E-Mail mit gefälschtem

Mehr

E-Mails versenden aber sicher! Secure E-Mail

E-Mails versenden aber sicher! Secure E-Mail E-Mails versenden aber sicher! Secure E-Mail Leitfaden S Kreisparkasse Verden 1 Vorwort Wir alle leben in einem elektronischen Zeitalter. Der Austausch von Informationen erfolgt zunehmend über elektronische

Mehr

Sicherheit in unternehmensübergreifenden Wertschöpfungsketten

Sicherheit in unternehmensübergreifenden Wertschöpfungsketten DEEN NNOVATION W CHSTUM Die Hightech-Strategie für Deutschland Sicherheit in unternehmensübergreifenden Wertschöpfungsketten Technical Showcase des Software-Clusters Softwareinnovationen für das digitale

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

Integration von SAP Netweaver mit Identity und Access Management

Integration von SAP Netweaver mit Identity und Access Management Integration von SAP Netweaver mit Identity und Access Management Integration von SAP Netweaver mit Identity und Access Management Unternehmenslösungen für sicheres und skalierbares Identity und Access

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

Allgemeine Erläuterungen zu

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

Mehr

Sichere Authentifizierung SSO, Password Management, Biometrie. 21.06.2007 Dr. Horst Walther, KCP hw@kuppingercole.de

Sichere Authentifizierung SSO, Password Management, Biometrie. 21.06.2007 Dr. Horst Walther, KCP hw@kuppingercole.de Sichere Authentifizierung SSO, Password Management, Biometrie 21.06.2007 Dr. Horst Walther, KCP hw@kuppingercole.de Single Sign-On, Password Management, Biometrie Single Sign-On: Anmeldung an mehreren

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

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

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

Mehr

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

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. 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

Installationsanleitung

Installationsanleitung Installationsanleitung POP3 und Bridge-Modus Inhaltsverzeichnis 1 POP3 und Bridge-Modus 2 1.1 Funktionsweise von POP3 mit REDDOXX 2 1.2 Betriebsarten 3 1.2.1 Standard-Modus 3 1.2.2 Bridge-Modus 6 1.2.3

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

Kapitel. Sicherheit. Seite. Kapitel. Sicherheit. Workplace & WebSphere Domino & Notes

Kapitel. Sicherheit. Seite. Kapitel. Sicherheit. Workplace & WebSphere Domino & Notes Sicherheit 99 9 Sicherheit 7. Ergänzungslieferung 02/2007 Ein ITP-Handbuch 9 Sicherheit 9 Moderne Anwendungen müssen einer Vielzahl von Anforderungen gerecht werden. Mit dem Siegeszug der IT in die Geschäftswelt

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

Business Rules und SOA. Parallelen und Synergien

Business Rules und SOA. Parallelen und Synergien Business Rules und SOA Parallelen und Synergien White Paper Januar 2008 Innovations Software Technology GmbH, 2008. Alle Rechte vorbehalten. Weitergabe und Vervielfältigung dieser Publikation oder von

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

Network Access Control für Remote Access: Best Practice Technical Paper

Network Access Control für Remote Access: Best Practice Technical Paper Network Access Control für Remote Access: Best Practice Technical Paper Stand Mai 2010 Haftungsausschluss Die in diesem Dokument enthaltenen Informationen können ohne Vorankündigung geändert werden und

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

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

Kundeninformation zu Secure Email. Secure Email Notwendigkeit?

Kundeninformation zu Secure Email. Secure Email Notwendigkeit? Kundeninformation zu Secure Email Digitale Raubzüge und Spionageangriffe gehören aktuell zu den Wachstumsbranchen der organisierten Kriminalität. Selbst modernste Sicherheitstechnologie bietet dagegen

Mehr

SOA Strategiebaukasten

SOA Strategiebaukasten SOA Strategiebaukasten predic8 GmbH Moltkestr. 40 53173 Bonn www.predic8.de info@predic8.de Inhalt Hintergrund, Strategie und Vision Topologie Governance Enterprise Metadata und Service Model Standards

Mehr

Kundenleitfaden Secure E-Mail

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

Mehr

Cloud Computing bereitet sich für den breiten Einsatz im Gesundheitswesen vor.

Cloud Computing bereitet sich für den breiten Einsatz im Gesundheitswesen vor. Cloud Computing im Gesundheitswesen Cloud Computing ist derzeit das beherrschende Thema in der Informationstechnologie. Die Möglichkeit IT Ressourcen oder Applikationen aus einem Netz von Computern zu

Mehr

Externer DNS. Technologien und Herausforderungen. Amanox Solutions AG Speichergasse 39 CH-3008 Bern

Externer DNS. Technologien und Herausforderungen. Amanox Solutions AG Speichergasse 39 CH-3008 Bern Externer DNS Technologien und Herausforderungen Amanox Solutions AG Speichergasse 39 CH-3008 Bern Wieso brauchen wir externen DNS Alle Internetservices nutzen DNS E-Mail Geschäftskritische Business Applikationen

Mehr

Kundeninformation zu Secure E-Mail

Kundeninformation zu Secure E-Mail S Sparkasse Höxter Kundeninformation zu Secure E-Mail,,Digitale Raubzüge und Spionageangriffe gehören aktuell zu den Wachstumsbranchen der organisierten Kriminalität. Selbst modernste Sicherheitstechnologie

Mehr

R016 Beilage 5: SOA-Glossar

R016 Beilage 5: SOA-Glossar Eidgenössisches Finanzdepartement EFD Informatiksteuerungsorgan des Bundes ISB R016 Beilage 5: SOA-Glossar Ausgabedatum: 2015-02-25 Version: 2.01 Status: Genehmigt Ersetzt: 2.0 Verbindlichkeit: Weisung

Mehr

Was ist Identity Management?

Was ist Identity Management? DECUS IT - Symposium 2005 Andreas Zickner HP Deutschland 2004 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice Problem IT Admin Mitarbeiter

Mehr

Dr. Thomas Lux XIONET empowering technologies AG Bochum, 20. Oktober 2005

Dr. Thomas Lux XIONET empowering technologies AG Bochum, 20. Oktober 2005 XIONET empowering technologies AG Bochum, 20. Oktober 2005 EIS Analyseorientierte Informationssysteme DSS Einkauf F u E MIS Lager Vertrieb Produktion Operative Informationssysteme Folie 2 Oktober 05 Anwender

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

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

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

Emailverschlüsselung mit Thunderbird

Emailverschlüsselung mit Thunderbird Emailverschlüsselung mit Thunderbird mit einer kurzen Einführung zu PGP und S/MIME Helmut Schweinzer 3.11.12 6. Erlanger Linuxtag Übersicht Warum Signieren/Verschlüsseln Email-Transport Verschlüsselung

Mehr

Kurzeinführung VPN. Veranstaltung. Rechnernetze II

Kurzeinführung VPN. Veranstaltung. Rechnernetze II Kurzeinführung VPN Veranstaltung Rechnernetze II Übersicht Was bedeutet VPN? VPN Typen VPN Anforderungen Was sind VPNs? Virtuelles Privates Netzwerk Mehrere entfernte lokale Netzwerke werden wie ein zusammenhängendes

Mehr

E-Mails versenden auf sicherem Weg! Sichere E-Mail Kundenleitfaden

E-Mails versenden auf sicherem Weg! Sichere E-Mail Kundenleitfaden E-Mails versenden auf sicherem Weg! Sichere E-Mail Kundenleitfaden Vorwort In unserem elektronischen Zeitalter erfolgt der Austausch von Informationen mehr und mehr über elektronische Medien wie zum Beispiel

Mehr

Oracle Business Process Analysis Suite. Gert Schüßler Principal Sales Consultant

<Insert Picture Here> Oracle Business Process Analysis Suite. Gert Schüßler Principal Sales Consultant Oracle Business Process Analysis Suite Gert Schüßler Principal Sales Consultant 1 Geschäftsprozesse Zerlegung am Beispiel Kreditvergabe Antrag aufnehmen Antrag erfassen Schufa Kunden

Mehr

- Architektur & Integration - Security in ADF Anwendungen (Essentials)

- Architektur & Integration - Security in ADF Anwendungen (Essentials) - Architektur & Integration - Security in ADF Anwendungen (Essentials) Markus Lohn Head of Technology Consulting, esentri AG E-Mail: markus.lohn@esentri.com +++ Bi%e wählen Sie sich in die Telefonkonferenz

Mehr

IT-Security als Enabler Attribut-basierte Autorisierung (ABAC) für das neue Kundenportal der CSS

IT-Security als Enabler Attribut-basierte Autorisierung (ABAC) für das neue Kundenportal der CSS IT-Security als Enabler Attribut-basierte Autorisierung (ABAC) für das neue Kundenportal der CSS Netclose Community Treffen, Horw, 24.09.2014 Stefan Allemann, CSS Versicherung CSS Versicherung - INTRAS

Mehr

Integrating Architecture Apps for the Enterprise

Integrating Architecture Apps for the Enterprise Integrating Architecture Apps for the Enterprise Ein einheitliches Modulsystem für verteilte Unternehmensanwendungen Motivation und Grundkonzept Inhalt Problem Ursache Herausforderung Grundgedanke Architektur

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

Rollen- und Kontext Basierte Autorisierung (RBAC) als Konzept für End-to-End Security in Verteilten Elektronischen Gesundheitsakten

Rollen- und Kontext Basierte Autorisierung (RBAC) als Konzept für End-to-End Security in Verteilten Elektronischen Gesundheitsakten Rollen- und Kontext Basierte Autorisierung (RBAC) als Konzept für End-to-End Security in Verteilten Elektronischen Gesundheitsakten Florian Wozak, Elske Ammenwerth, Ruth Breu, Richard Mair, Robert Penz,

Mehr

Das Plus an Unternehmenssicherheit

Das Plus an Unternehmenssicherheit Out-of-The-Box Client Security Das Plus an Unternehmenssicherheit ic Compas TrustedDesk Logon+ Rundum geschützt mit sicheren Lösungen für PC-Zugang, Dateiverschlüsselung, Datenkommunikation und Single

Mehr

Use-Cases. Bruno Blumenthal und Roger Meyer. 17. Juli 2003. Zusammenfassung

Use-Cases. Bruno Blumenthal und Roger Meyer. 17. Juli 2003. Zusammenfassung Use-Cases Bruno Blumenthal und Roger Meyer 17. Juli 2003 Zusammenfassung Dieses Dokument beschreibt Netzwerk-Szenarios für den Einsatz von NetWACS. Es soll als Grundlage bei der Definition des NetWACS

Mehr

www.seppmail.ch SEPPMAIL DIE FUHRENDE LOSUNG FUR DEN SICHEREN E-MAIL-VERKEHR Verschlüsselung / digitale Signatur / Managed PKI

www.seppmail.ch SEPPMAIL DIE FUHRENDE LOSUNG FUR DEN SICHEREN E-MAIL-VERKEHR Verschlüsselung / digitale Signatur / Managed PKI www.seppmail.ch SEPPMAIL DIE FUHRENDE LOSUNG FUR DEN SICHEREN E-MAIL-VERKEHR Verschlüsselung / digitale Signatur / Managed PKI SEPPMAIL MACHT E-MAILS SICHER SOFORT, OHNE SCHULUNG EINSETZBAR KOMFORT UND

Mehr

E-Mail-Verschlüsselung für Unternehmen Basics und Trends im Jahr 2015

E-Mail-Verschlüsselung für Unternehmen Basics und Trends im Jahr 2015 E-Mail-Verschlüsselung für Unternehmen Basics und Trends im Jahr 2015 E-Mail-Verschlüsselung für Unternehmen Basics und Trends im Jahr 2015 Warum Inhalte und nicht nur Übertragungswege verschlüsseln? Standards:

Mehr

Die Rückkehr der Einfachheit 62

Die Rückkehr der Einfachheit 62 7.09 Plus CD! Stellenmarkt S. 58 Das war die JAX 2009 S. 15 Deutschland 7,50 Österreich 8,60 Schweiz sfr 15,80 Java Magazin Java Architekturen SOA Agile www.javamagazin.de CD-Inhalt JavaRebel 2.0 Squish

Mehr

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

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

Mehr

Von 0 auf SOA in 10 Schritten. Stefan Tilkov innoq stefan.tilkov@innoq.com

Von 0 auf SOA in 10 Schritten. Stefan Tilkov innoq stefan.tilkov@innoq.com Von 0 auf SOA in 10 Schritten Stefan Tilkov innoq stefan.tilkov@innoq.com 1 Stefan Tilkov Geschäftsführer und Principal Consultant, innoq Deutschland GmbH Fokus auf SOA, Web-Services, REST SOA-Editor InfoQ.com

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

Technische Dokumentation Scalera Mailplattform MS Entourage Konfigruation unter Mac OS X für EveryWare Kunden

Technische Dokumentation Scalera Mailplattform MS Entourage Konfigruation unter Mac OS X für EveryWare Kunden Technische Dokumentation Scalera Mailplattform MS Entourage Konfigruation unter Mac OS X für EveryWare Kunden Vertraulichkeit Das vorliegende Dokument beinhaltet vertrauliche Informationen und darf nicht

Mehr

Sicherheitsaspekte unter Windows 2000

Sicherheitsaspekte unter Windows 2000 Sicherheitsaspekte unter Windows 2000 Margarete Kudak Sascha Wiebesiek 1 Inhalt 1. Sicherheit 1.1 Definition von Sicherheit 1.2 C2 - Sicherheitsnorm 1.3 Active Directory 2. Sicherheitslücken 3. Verschlüsselung

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

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

OFTP2 - Checkliste für die Implementierung

OFTP2 - Checkliste für die Implementierung connect. move. share. Whitepaper OFTP2 - Checkliste für die Implementierung Die reibungslose Integration des neuen Odette-Standards OFTP2 in den Datenaustausch- Workflow setzt einige Anpassungen der Systemumgebung

Mehr