Kontextbezogene Zugriffskontrolle für BPEL (Engines)

Größe: px
Ab Seite anzeigen:

Download "Kontextbezogene Zugriffskontrolle für BPEL (Engines)"

Transkript

1 Institut für Architektur von Anwendungssystemen Abteilung Workflow Applications Universität Stuttgart Universitätsstraße 38 D Stuttgart Diplomarbeit Nr Kontextbezogene Zugriffskontrolle für BPEL (Engines) Heiko Görig Studiengang: Softwaretechnik Prüfer: Prof. Dr. Frank Leymann Betreuer: Dipl. Inf. Tobias Anstett Dipl. Inf. Kieredin Allister Garbaa begonnen am: beendet am: CR-Klassifikation: D.2.12, H.4.1, K.1, K.6.5

2

3 Inhaltsverzeichnis Verzeichnis der Abbildungen...III Verzeichnis der Listings...V Verzeichnis der Abkürzungen...VII 1 Einleitung Grundlagen SOA Web Services Sicherheit in verteilten Softwareumgebungen Sicherheit in BPEL Engines Kommunikation mit BPEL Prozessen Beispielprozess Absicherung der eingehenden Kommunikation Speicherung, Struktur und Abfrage von Benutzerinformationen Zugriffskontrolle Zuweisung von Benutzerinformationen Absicherung der ausgehenden Kommunikation Auditing sicherheitsrelevanter Ereignisse Konzept & Spezifikation Anforderungen Konzepte Spracherweiterungen Anwendungsfälle Entwurf & Implementierung Verwendete Technologien Orchestration Director Engine Sicherheitskomponente Erweiterungen der Apache ODE Web Service Caller Zusammenfassung Ausblick A Grafische Oberflächen Literaturverzeichnis I

4

5 Verzeichnis der Abbildungen Abbildung 2.1: Dynamic Binding im SOA Dreieck (vgl. [WCL+05])...4 Abbildung 2.2: Enterprise Service Bus (vgl. [Flu07])...5 Abbildung 2.3: Sicherheitstaxonomie...10 Abbildung 2.4: Point-to-Point Security durch Transport-Layer Security...18 Abbildung 2.5: End-to-End Security durch Message-Layer Security...19 Abbildung 2.6: Single Sign-On mit einem Security Token Service (STS)...20 Abbildung 3.1: Darstellung eines BPEL Prozesses...28 Abbildung 3.2: Verarbeitungsprozess von Nachrichten...29 Abbildung 3.3: BPMN-Modell des Beispielprozesses...30 Abbildung 3.4: BPMN-Modell des Beispielprozesses mit Sicherheitsanforderungen...32 Abbildung 3.5: Abstraktionsschicht zwischen BPEL Engine und Identity Services...46 Abbildung 4.1: User Context, Security Context und Security Domain...63 Abbildung 4.2: User References...64 Abbildung 4.3: Service Abstraction...65 Abbildung 4.4: Security Domain Composition...66 Abbildung 5.1: Architektur der Apache ODE...92 Abbildung 5.2: Laden und Speichern des Security Descriptors...98 Abbildung 5.3: Zugriff auf Eigenschaften eines LDAP Benutzers...99 Abbildung 5.4: Änderungen und Erweiterungen der BPEL Engine Apache ODE Abbildung A.1: Apache ODE Security Settings: Hauptansicht Abbildung A.2: Apache ODE Security Settings: Benutzerverwaltung Abbildung A.3: Apache ODE Security Settings: Zugriffsrechteverwaltung Abbildung A.4: Apache ODE Security Settings: Endpunkteverwaltung (1) Abbildung A.5: Apache ODE Security Settings: Endpunkteverwaltung (2) Abbildung A.6: Apache ODE Security Settings: Endpunkteverwaltung (3) Abbildung A.7: Apache ODE Security Settings: Endpunkteverwaltung (4) Abbildung A.8: Web Service Caller III

6

7 Verzeichnis der Listings Listing 2.1: Policy mit benutzerdefinierten Policy Assertions...7 Listing 2.2: SOAP Header mit Benutzername und Passwort...21 Listing 2.3: Security Policy für passwortgeschützte Web Services...22 Listing 2.4: Beispiel einer XACML Policy...24 Listing 2.5: Beispiel eines XACML Decision Requests...25 Listing 3.1: Authentifizierung innerhalb des Workflows...34 Listing 3.2: Security Policy für den eingehenden Endpunkt des Beispielprozesses...37 Listing 3.3: Policy Assertion zur Definition von Schlüsselzugriffen...38 Listing 3.4: Policy Assertion zur Definition des Authentification Services...39 Listing 3.5: Übergabe von Benutzerinformationen über das Attribut usercontext...41 Listing 3.6: Zugriff auf den Benutzerkontext durch eine Ressourcenabfrage...43 Listing 3.7: Benutzerinformationen zu einem Prozessaufruf...45 Listing 3.8: Definition eines Identity Services...45 Listing 3.9: Abfrage von Benutzerattributen...45 Listing 3.10: Deklarative Autorisierung innerhalb des Prozesses...47 Listing 3.11: XACML Policy für die Operation startorder des Beispielprozesses...49 Listing 3.12: Zuweisung von Benutzerinformationen über das Attribut runas...53 Listing 3.13: Zuweisung von Benutzerinformationen im Deployment Descriptor...54 Listing 3.14: Zuweisung statischer Benutzerinformationen im Deployment Descriptor 54 Listing 4.1: Angabe des Security Descriptors im Deployment Descriptor...68 Listing 4.2: XML Schema des Elements Property...70 Listing 4.3: XML Schema des Elements User...71 Listing 4.4: XML Schema des Typs UserContext...71 Listing 4.5: Definition von Benutzern im Deployment Descriptor...74 Listing 4.6: Initialisierung einer Variablen mit Benutzerinformationen...74 Listing 5.1: Aufbau des Security Descriptors...97 Listing 5.2: Datei-interne Benutzerverwaltung Listing 5.3: LDAP-basierte Benutzerverwaltung Listing 5.4: Datei-interne Zugriffsrechteverwaltung Listing 5.5: Datei-interne Endpunkteverwaltung Listing 5.6: User Element mit zusätzlichen Benutzerinformationen V

8

9 Verzeichnis der Abkürzungen AES Advanced Encryption Standard API Application Programming Interface BPEL Business Process Execution Language BPMN Business Process Modeling Notation DAO Data Access Object DES Data Encryption Standard DOM Document Object Model ERP Enterprise Resource Planning ESB Enterprise Service Bus HTTP Hypertext Transfer Protocol HTTPS Hypertext Transfer Protocol Secure IMA Inbound Message Activity LDAP Lightweight Directory Access Protocol OASIS Organization for the Advancement of Structured Information Standards OSI Open Systems Interconnection PKI Public Key Infrastructure PDP Policy Decision Point PEP Policy Enforcement Point SAML Security Assertion Markup Language SOA Service Oriented Architecture SOAP ursprünglich: Simple Object Access Protocol jetzt: kein Akronym mehr SOX Sarbanes-Oxley Act SPML Service Provisioning Markup Language SSO Single Sign-On STS Security Token Service TLS Transport Layer Security W3C World Wide Web Consortium WfMS Workflow Management System WSDL Web Service Description Language WS-RM Web Services Reliable Messaging WSS Web Services Security XACML Extensible Access Control Markup Language XML Extensible Markup Language VII

10

11 Kapitel 1: Einleitung Kapitel 1 Einleitung Geschäftsprozesse werden heutzutage als wichtige Ressourcen eines Unternehmens angesehen und sind von strategischer Bedeutung. Sie beschreiben Arbeitsabläufe, die z.b. innerhalb eines Unternehmens oder zwischen Unternehmen (Business to Business) auftreten. Ein solcher Arbeitsablauf besteht aus einer Abfolge von Einzelaktivitäten, die entweder manuell oder automatisiert ausgeführt werden. Die Aktionen innerhalb einer Einzelaktivität können dabei einen elementaren Wert (Business Value) für die jeweiligen Unternehmen haben. So werden beispielsweise vertrauliche Informationen ausgetauscht, Transaktionen getätigt oder Verträge abgeschlossen. Aus diesem Grund ist es außerordentlich wichtig, dass Geschäftsprozesse in einem Umfeld ausgeführt werden, in dem Schutz vor unberechtigten Zugriffen und eine (abhör-)sichere Kommunikation gewährleistet sind. Zudem müssen, häufig auch aufgrund gesetzlicher Bestimmungen (z.b. SOX,1 EUROSOX2, Basel II3), alle ausgeführten Einzelaktivitäten zu einem späteren Zeitpunkt nachweisbar, nachvollziehbar und damit revisionssicher sein. Infolgedessen ist die Umsetzung dieser Sicherheitsanforderungen für die Ausführung von Geschäftsprozessen von zentraler Bedeutung. Workflows sind Geschäftsprozesse, die IT-gestützt von sog. Workflow Engines oder Workflow Management Systemen (WfMS) ausgeführt werden. Da ein Workflow das digitale Äquivalent zu einem Geschäftsprozess ist, setzt er dieselben Sicherheitsanforderungen voraus. Konkret bedeutet dies, dass Nachrichten, die mit einem Workflow ausgetauscht werden, ebenfalls abgesichert sein müssen. Zudem ist eine Zugriffskontrolle nötig, die nicht berechtigten Identitäten (Personen, Systemen, etc.) den Zugriff auf Workflows oder Aktivitäten innerhalb eines Workflows verbietet. Falls ein Zugriff berechtigt ist, sollten Aktivitäten während und nach ihrer Ausführung denjenigen Identitäten zugeordnet werden können, die sie veranlasst haben. Dadurch lassen sich insbesondere Zuständigkeiten und Verantwortlichkeiten klären. Die Umsetzung dieser Anforderungen setzt zunächst die Einbettung eines Workflows in sein organisatorisches Umfeld voraus. Hierzu müssen Identitäten und Richtlinien defi ( ) ( ) ( ) 1

12 Kapitel 1: Einleitung niert werden, die bei der Ausführung eines Workflows eine Rolle spielen. Ein Workflow muss zudem mit denjenigen Identitäten, die an ihm beteiligt sind, in einen Kontext gebracht werden. Ein solcher Benutzerkontext muss Informationen darüber enthalten, welche Aktivitäten eines Prozesses im Namen welcher Identität ausgeführt werden. Der de facto Standard für die Definition von Workflows im Web Service Umfeld ist die Business Process Execution Language (WS-BPEL). Zur Umsetzung der oben genannten Funktionen kann daher auf die zahlreichen Sicherheitsspezifikationen, die bereits für Web Services existieren, zurückgegriffen werden. Diese Spezifikationen können jedoch nur als Basis zur Absicherung von BPEL Prozessen verwendet werden, weil sie beispielsweise keine Aussagen darüber machen, wie Dienste zur Authentifizierung oder Zugriffskontrolle integriert werden. Da auch der WS-BPEL Standard keine Aussagen bzgl. Sicherheit trifft, sondern sich ganz auf den funktionalen Teil beschränkt, wurde die Umsetzung der oben genannten Sicherheitsanforderungen in vielen BPEL Engines unterschiedlich realisiert. In dieser Arbeit werden unterschiedliche Lösungen zur Realisierung von kontextbezogener Sicherheit in BPEL Engines erarbeitet und untersucht. Ziel ist die Entwicklung eines Sicherheitskonzeptes für BPEL Engines und dessen prototypische Implementierung. Kapitel 2 vermittelt zunächst die Grundlagen, die dazu notwendig sind. Anschließend werden in Kapitel 3 anhand eines Beispielprozesses die konkreten Sicherheitsanforderungen von Workflows ermittelt und mögliche Umsetzungsalternativen in BPEL Engines vorgestellt und diskutiert. Im darauf folgenden Kapitel 4 wird auf Grundlage der Umsetzungsalternativen ein Sicherheitskonzept für die Apache Orchestration Director Engine entwickelt. Anschließend folgt in Kapitel 5 eine Beschreibung der Umsetzung des Konzepts. Kapitel 6 liefert abschließend eine Zusammenfassung dieser Arbeit. Die Diplomarbeit wurde in Kooperation mit der Robert Bosch GmbH durchgeführt. Im Rahmen der Zusammenarbeit wurden verschiedene Geschäftsprozesse des Geschäftsbereichs Diesel Gasoline Systems (DGS) modelliert, die zum Verständnis der Sicherheitsanforderungen von Geschäftsprozessen beigetragen haben. 2

13 Kapitel 2: Grundlagen Kapitel 2 Grundlagen Dieses Kapitel vermittelt die theoretischen Grundlagen, die für ein Verständnis der vorliegenden Arbeit erforderlich sind. Zunächst wird das Konzept der Service-orientierten Architektur erläutert. Die anschließend in 2.2 beschriebene Web Service Technologie stellt eine Umsetzung dieses Architekturkonzepts dar. Kapitel 2.3 liefert eine Einführung zum Thema Sicherheit in verteilten Softwareumgebungen, zu deren Komponenten ein BPEL Prozess gezählt werden kann. Ausgehend von bestehenden Risiken werden zunächst die Sicherheitsanforderungen ermittelt, die in verteilten Softwareumgebungen bestehen können. Anschließend werden Konzepte vorgestellt, durch die die erhobenen Sicherheitsanforderungen erfüllt werden können. Diese Konzepte sind ihrerseits hierarchisch in Dienste, Mechanismen und Standards aufgeteilt. 2.1 SOA Service-orientierte Architektur (Service-Oriented Architecture, SOA) ist ein Architekturkonzept, welches die Entwicklung und Integration heterogener, verteilter Softwaresysteme vereinfachen soll. Ein System wird als heterogen bezeichnet, wenn es aus Komponenten besteht, die auf unterschiedlichen und potentiell zueinander inkompatiblen Technologien (Betriebssystemen, Programmiersprachen, usw.) basieren. Zwei Komponenten sind verteilt, wenn sie in physikalisch oder logisch voneinander getrennten Umgebungen ausgeführt werden. Die SOA bietet Konzepte zur Integration solcher Komponenten und ermöglicht damit den Aufbau einer verteilten Softwareumgebung. Die in diesem Kapitels verwendeten Begrifflichkeiten sind aus [Erl08] und aus [WCL+05] entnommen. Grundlage einer SOA bilden Dienste (Services), die bestimmte Funktionalitäten implementieren und von sog. Service Providers bereitgestellt werden. Jeder Dienst verfügt über einen sog. Service Contract, der beschreibende Informationen, auch Metadaten genannt, zu dem jeweiligen Dienst enthält. Die Metadaten spezifizieren in standardisierten und maschinenlesbaren Sprachen, welchen Zweck der Dienst verfolgt, welche Funktionen er bereitstellt und wie diese Funktionen aufgerufen werden können. Da keine Aussagen über die konkrete Implementierung des Dienstes getroffen werden, spricht man 3

14 Kapitel 2: Grundlagen Abbildung 2.1: Dynamic Binding im SOA Dreieck (vgl. [WCL+05]) auch von einer abstrakten Schnittstellenbeschreibung. Ein sog. Service Requestor kann sich mit Hilfe des Service Contracts an den entsprechenden Dienst binden (bind) und dessen Funktionen verwenden. Als Binden wird hierbei der Vorgang bezeichnet, in dem Adressen, Übertragungsprotokolle und Nachrichtenformate der Funktionsaufrufe festgelegt werden. Um einen Dienst auffindbar zu machen, kann dessen Service Contract in einer sog. Discovery Facility veröffentlicht werden. Ein Service Requestor kann dort nach Diensten suchen und deren Service Contracts anfordern. Diese können wiederum verwendet werden, um sich an die entsprechenden Dienste zu binden und deren Funktionen zu nutzen. Der beschriebene Prozess wird auch als Dynamic Binding bezeichnet und ist im sog. SOA Dreieck (siehe Abbildung 2.1) abgebildet. Ein Service Contract enthält die abstrakte Schnittstellenbeschreibung eines Dienstes. Dadurch, dass die Kommunikation mit einem Dienst ebenfalls auf eine standardisierte Weise erfolgt, sind die internen Mechanismen eines Dienstes für einen Service Requestor vollkommen transparent. Dienste können jederzeit geändert oder ausgetauscht werden, ohne dass sich dadurch Änderungen für einen Service Requestor ergeben. Dieses Prinzip der Kapselung und Austauschbarkeit wird auch als Service Abstraction bezeichnet. Sog. Adaptoren können verwendet werden, um Komponenten (Anwendungen, Module etc.), die ursprünglich nicht als Dienste konzipiert wurden, in eine SOA-Umgebung zu integrieren. Im Bereich der betrieblichen Anwendungen wird dies auch als Enterprise Application Integration (EAI) bezeichnet. Ein weiteres wichtiges Prinzip einer SOA ist die Kombinierbarkeit von Diensten (Service Composability): Ein Dienst kann beliebige andere Dienste nutzen, deren Funktionalität kombinieren und auf diese Weise neue Funktionen generieren. Dieser Prozess wird auch als Orchestrierung (Orchestration) bezeichnet und kann auf verschiedene Arten realisiert werden. Zum einen können die Dienste mit Hilfe traditioneller Programmiersprachen in jeweils eigenen Anwendungen kombiniert werden. Eine andere Möglichkeit ist, die Orchestrierung in einer speziell für diesen Zweck entwickelten Sprache zu beschreiben und von einer Laufzeitumgebung interpretieren und ausführen zu lassen. Die Business Process Execution Language (BPEL) ist ein Beispiel für eine solche Sprache. Eine BPEL Engine entspricht einer Laufzeitumgebung für die Sprache BPEL. 4

15 Kapitel 2: Grundlagen Um die Integration von Komponenten sowie deren Kommunikation innerhalb einer SOA zu vereinfachen, wird häufig ein sog. Enterprise Service Bus (ESB) eingesetzt ESB Bei einem ESB handelt es sich um eine Middleware Komponente, die in einer verteilten Softwareumgebungen die Vermittlung (mediation) von Nachrichten übernimmt (vgl. [FrN08], [Flu07]). Abbildung 2.2: Enterprise Service Bus (vgl. [Flu07]) Statt Nachrichten direkt auszutauschen, können Dienste über einen ESB kommunizieren (siehe Abbildung 2.2). Dies führt zu einer Reduzierung der Abhängigkeiten zwischen den Diensten: Statt einen Dienst direkt aufzurufen, kann ein Service Requestor dies dem ESB überlassen. Dazu übergibt er dem ESB die Nachricht und Informationen über den aufzurufenden Dienst. Der ESB löst den Dienst auf und leitet die Nachricht an diesen weiter. Falls nötig können von dem ESB noch weitere Schritte, wie z.b. eine Konvertierung oder Transformation der Nachricht durchgeführt werden. Auf diese Weise können Service Requestors von der Identität, der Adresse, dem Übertragungsprotokoll und der Schnittstelle eines Dienstes entkoppelt werden. Diese Entkopplung wird auch als Service Virtualization bezeichnet. Eine zweite wichtige Funktionalität von ESBs ist die sog. Aspect-oriented Connectivity: Service-orientierte Systeme verfügen häufig über Anforderungen, die an mehreren Stellen des Systems erfüllt sein müssen. Zu solchen übergreifenden Anforderungen, auch Cross-cutting Concerns genannt, gehören beispielsweise Aspekte wie Sicherheit, Fehlerbehandlung oder Logging. Ein ESB ist in der Lage, Service Requestors und Providers die Berücksichtigung dieser Aspekte abzunehmen. Ein ESB könnte beispielsweise so konfiguriert werden, dass er, abhängig von Sender und Empfänger, Nachrichten unterschiedlich verschlüsselt und signiert. Durch die Verlagerung derartiger Funktionalitäten 5

16 Kapitel 2: Grundlagen auf einen ESB, wird die Komplexität von Service Requestors und Providers reduziert und in infolgedessen deren Implementierung vereinfacht. 2.2 Web Services Die Web Service Technologie ist eine offene, auf Standards basierende Realisierung einer SOA [WCL+05]. Die Standards werden von internationalen Organisationen wie dem World Wide Web Consortium (W3C) oder der Organization for the Advancement of Structured Information Standards (OASIS) entwickelt und von einem großen Teil der IT-Industrie getragen. Durch diese breite Unterstützung hat sich die Web Service Technologie innerhalb der letzten zehn Jahre zu einer Schlüsseltechnologie für die Entwicklung verteilter Softwaresysteme und die Integration von Unternehmensanwendungen (EAI) entwickelt. Ein Web Service entspricht der Implementierung eines Dienstes, wie er in 2.1 definiert wurde. Die Web Service Description Language (WSDL) ist die standardisierte und maschinenlesbare Sprache, die zur Beschreibung von Web Services verwendet wird. In einem WSDL-Dokument wird ein Web Service durch abstrakte und konkrete Elemente definiert. Die abstrakten Elemente beschreiben die Schnittstelle eines Web Services als eine Menge von Operationen, die jeweils ein- und ausgehende Nachrichten eines bestimmten Datentyps besitzen. Sie machen jedoch keine Angaben darüber, wie sich ein Service Requestor an den Web Service binden kann. Dies wird durch konkrete Elemente erreicht, in denen die Netzwerkadressen sowie die jeweils zu verwendenden Transport- und Kommunikationsprotokolle (das Binding) eines Web Services festgelegt werden. Eine solche Kombination aus Netzwerkadresse und Binding wird auch als Endpunkt (Endpoint) bezeichnet. Weitere Informationen zur WSDL können der Spezifikation [WSDL07] entnommen werden. Für den Nachrichtenaustausch mit Web Services kommt meist das Kommunikationsprotokoll SOAP ([SOAP07]) zum Einsatz, welches ursprünglich für den Aufruf entfernter Funktionen (Remote Procedure Call, RPC) entwickelt wurde. Eine SOAP-Nachricht ist ein XML Dokument, das als XML Wurzelelement einen sog. SOAP-Envelope (Umschlag) besitzt. Der SOAP-Envelope besteht aus einem SOAP-Body und einem optionalen SOAP-Header. Der SOAP-Body enthält die Nutzdaten der Nachricht und ist nur für den Empfänger einer Nachricht, den sog. Ultimate Recipient, bestimmt. In den Nutzdaten können z.b. Name und Parameter der aufzurufenden Funktion angegeben werden. Der SOAP-Header besteht aus einzelnen Header-Elementen, in denen Informationen gegeben werden, die für die Übermittlung oder Verarbeitung einer Nachricht von Bedeutung sind. Dies können beispielsweise Angaben über den Empfänger (z.b. dessen Adresse), den Absender (z.b. dessen Name) oder die Verschlüsselung der Nachricht sein. Über ein Attribut kann angegeben werden, für wen das Header-Element bestimmt ist. Dies kann entweder der Ultimate Recipient oder ein Intermediary sein. Als Intermediaries werden hierbei alle Stationen bezeichnet, die sich zwischen Sender und Ultimate Receiver befinden. Ein Intermediary darf die für ihn bestimmten Header-Elemente entfernen und neue Header-Elemente hinzufügen. Auf diese Weise ist es beispielsweise möglich, dass zwei Intermediaries eine SOAP-Nachricht ver- und wieder entschlüsseln, ohne das Sender und Ultimate Recipient etwas darüber erfahren. 6

17 Kapitel 2: Grundlagen Da sowohl WSDL als auch SOAP auf XML aufbauen, können sie beliebig erweitert werden. Im Laufe der Zeit wurden eine Vielzahl solcher Erweiterungen in eigenen Standards spezifiziert. Ein Beispiel dafür ist der im Folgenden beschriebene Standard WSPolicy WS-Policy WS-Policy ist ein Standard des World Wide Web Consortium (W3C). Er liefert ein Rahmenwerk, um domänenspezifische Fähigkeiten, Anforderungen und Merkmale von Web Services zu beschreiben (vgl. [WPF07]). Die domänenspezifischen Eigenschaften werden dabei als Policy Assertions bezeichnet. WS-Policy definiert ein Modell, mit dem Policy Assertions zu Policies (Richtlinien) zusammengefasst werden. Eine solche Policy kann mit beliebigen WSDL-Elementen verknüpft werden. Durch die Verknüpfung wird festgelegt, dass die Policy für die entsprechenden Elemente gelten soll. Dies wird anhand von Listing 2.1 verdeutlicht. 1 <wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" 2 xmlns:wsp="http://www.w3.org/ns/ws-policy" 3 xmlns:wsu=" /01/oasis wss-wssecurity-utility-1.0.xsd"> 4 <wsp:policy xmlns="http://org-custom-assertions" wsu:id="mypolicy"> 5 <EncryptResponse /> 6 <SignResponse /> 7 </wsp:policy> 8 [...] 9 <wsdl:binding name="securebinding" type="orderinterface"> 10 <wsp:policyreference URI="#MyPolicy"/> 11 [...] 12 </wsdl:binding> 13 [...] 14 <wsdl:definitions/> Listing 2.1: Policy mit benutzerdefinierten Policy Assertions Im Beispiel wird eine Policy mit zwei Policy Assertions angegeben (Policy, Zeile 4-7). Die Policy Assertions definieren, dass Antwortnachrichten verschlüsselt und signiert werden sollen. Die Policy wird durch eine Policy Reference mit einem Binding des Web Services verknüpft (PolicyReference, Zeile 10). Dadurch wird festgelegt, dass bei Verwendung des Bindings alle Antwortnachrichten entsprechend abzusichern sind. Damit diese Vorgänge stattfinden, muss eine Web Service Engine die in der Policy definierte Funktionalität umsetzen können. Die Engine muss die enthaltenen Policy Assertions kennen und entsprechend verarbeiten können. Um die Interoperabilität zu verbessern, wurden für verschiedene Anwendungsgebiete Standards verabschiedet, in denen die Struktur und Bedeutung von Policy Assertions definiert wird. Beispiele hierfür sind etwa WS-SecurityPolicy und WS-RM Policy4, mit denen Sicherheitsanforderungen bzw. Anforderungen an die zuverlässige Nachrichtenübertragungen ausgedrückt werden können. 4 ( ) 7

18 Kapitel 2: Grundlagen 2.3 Sicherheit in verteilten Softwareumgebungen Eine verteilte Softwareumgebung besteht aus unterschiedlichen Komponenten, die auf physikalisch oder logisch voneinander getrennten Systemen ausgeführt werden. Die Komponenten können über Netzwerke, welche die Systeme untereinander verbinden, Nachrichten austauschen und so miteinander kommunizieren. Dabei handelt es sich häufig um Netzwerke, wie z.b. das Internet, die sich der Kontrolle der jeweiligen Kommunikationspartner entziehen und zahlreiche Sicherheitsrisiken bergen. Speziell in Umgebungen, die nach den Prinzipien der SOA aufgebaut sind, stellt Sicherheit eine besondere Herausforderung dar. Schnittstellenbeschreibungen eines Dienstes sind standardisiert und selbst beschreibend. Damit werden Informationen über den Dienst preisgegeben, die einen Angriff erleichtern. Aus diesem Grund müssen Vorkehrungen zur Absicherung der Kommunikation getroffen werden. Diese spielen auch in vermeintlich sicheren Netzwerken (unternehmens-interne Intranets etc.) eine Rolle, in denen Faktoren wie die Geheimhaltung von Nachrichten ebenfalls von großer Bedeutung sein können. Ausgehend von den Sicherheitsrisiken, werden im Folgenden zunächst die Sicherheitsanforderungen ermittelt, die in verteilten Softwareumgebungen bestehen können. Anschließend werden Konzepte vorgestellt, die zur Erfüllung dieser Sicherheitsanforderungen entwickelt wurden Sicherheitsrisiken Zwischen Sender und Empfänger einer Nachricht befinden sich praktisch immer mehrere Zwischenstationen (intermediaries), die potentielle Sicherheitslücken (security vulnerabilities) darstellen. Ein Angreifer, der einen Intermediary unter seine Kontrolle gebracht hat, stellt auf verschiedene Arten eine Bedrohung dar. In [Pap07] werden diese Bedrohungen, ausgehend von dem WS-I Basic Security Profile [WSI07], in folgende Kategorien unterteilt: Nicht-autorisierter Zugriff (unauthorized access) Geheime Informationen innerhalb einer Nachricht, wie z.b. Passwörter oder Firmendaten, werden von einem Angreifer eingesehen. Nicht-autorisierte Änderung von Nachrichten (unauthorized alteration of messages) Eine Nachricht wird von einem Angreifer modifiziert, ersetzt oder mehrmals gesendet und von dem Empfänger dennoch als authentisch angesehen. Ein Angreifer könnte durch einen solchen Angriff beispielsweise Geldüberweisungen manipulieren oder mehrfach ausführen. Diese Kategorie lässt sich in verschiedene Angriffsarten, wie z.b. falsified messages, replay attacks oder session hijacking, unterteilen. Man in the middle Ein Angreifer der einen Intermediary unter seiner Kontrolle hat, fängt Nachrichten zwischen zwei Parteien ab und gibt sich bei diesen als der jeweils andere Kommunikationspartner aus. Da die beiden Parteien davon ausgehen, dass sie direkt miteinander kommunizieren, werden möglicherweise geheime Informationen ausgetauscht, die der Angreifer dann einsehen kann. 8

19 Kapitel 2: Grundlagen Eine weitere Bedrohung, die besonders im E-Business von Bedeutung ist und nicht in die genannten Kategorien eingeordnet werden kann, ist die Repudiation Der Sender einer Nachricht streitet den Versand der Nachricht ab, obwohl dieser stattgefunden hat. Ein Motiv könnte sein, dass der Sender sich Verpflichtungen entziehen will, die mit dem Versand der Nachricht verbunden sind Sicherheitsanforderungen Aus den vorgestellten Sicherheitsrisiken können für die Übermittlung von Nachrichten folgende Sicherheitsanforderungen abgeleitet werden (vgl. [CDK05]): Vertraulichkeit (confidentiality/privacy/secrecy) Nachrichten sollen nur von denjenigen Benutzern gelesen werden können, die dazu berechtigt sind. Integrität (integrity) Nachrichten sollen auf dem Weg vom Sender zum Empfänger nicht verändert werden. Falls eine Nachricht verändert wurde, sollte dies für den Empfänger erkennbar sein können. Authentizität (authenticity) Nachrichten sollen eindeutig dem Sender zugeordnet werden können und die Identität des Senders sollte verifizierbar sein. Einmaligkeit (uniqueness) Nachrichten sollen eindeutig identifizierbar sein, so dass ein erneutes Senden der Nachricht (replay) erkannt werden kann. Verbindlichkeit (non-repudiation) Sender von Nachrichten sollen nicht in der Lage sein ihre Urheberschaft abzustreiten. Besteht eine Verbindung zwischen zwei Anwendungen (z.b. einer Client- und ServerAnwendung), in der diese Anforderungen in beide Richtungen erfüllt werden, spricht man von einem Secure Channel. Die Gesamtheit der sicherheitsrelevanten Daten, die bzgl. der jeweils anderen Anwendung existieren, wird als Sicherheitskontext (Security Context) bezeichnet. Dazu gehören beispielsweise Schlüssel, Richtlinien und sonstige Informationen, die dem Kommunikationspartner zugeordnet werden können (vgl. [SFH05+], [Pap07]). Wenn zwei Anwendungen Nachrichten über einen Secure Channel schicken, tun sie dies jeweils im Namen (on behalf) einer bestimmten Entität. Beispiele für solche Entitäten sind etwa Personen oder Prozesse. Über die Nachrichten greifen sie auf Ressourcen der jeweils anderen Anwendung zu. Dabei können neben Dokumenten auch Web Services oder Workflows als Ressourcen angesehen werden. Ein System stellt in der Regel eine Vielzahl an verschiedenen Ressourcen zur Verfügung. Nicht jeder, der eine sichere 9

20 Kapitel 2: Grundlagen Verbindung zu dem System aufbauen kann, sollte jedoch auch Zugriff auf alle Ressourcen haben. So sollte ein für Mitarbeiter zugängliches Enterprise Resource Planning (ERP) System beispielsweise verhindern, dass Mitarbeiter eigene Urlaubsanträge genehmigen oder sich selbst in den Genuss von Gehaltserhöhungen bringen. Aus diesem Grund ergibt sich eine weitere Sicherheitsanforderung: Zugriffsschutz (access protection) Aktionen auf Ressourcen sollen nur von denjenigen Benutzern des Systems ausgeführt werden können, die dazu berechtigt sind. Um die genannten Anforderungen zu erfüllen, wurden verschiedene Konzepte entwickelt. In Anlehnung an [SFH05+] und [BAB+07] werden diese im Folgenden in Sicherheitsdienste, Sicherheitsmechanismen sowie Sicherheitsstandards aufgeteilt und in einer Taxonomie angeordnet (siehe Abbildung 2.3). Abbildung 2.3: Sicherheitstaxonomie Sicherheitsdienste sind allgemeine Schutzvorrichtungen, welche die Sicherheitsanforderungen von Systemen erfüllen sollen. Sind bilden die oberste Ebene der Taxonomie. Zu beachten ist, das es sich nicht notwendigerweise um Dienste handeln muss, wie sie in 2.1 beschrieben sind. Gegebenenfalls kann ein Sicherheitsdienst auch eng an ein System gekoppelt sein. Intern wendet ein Sicherheitsdienst beliebig viele Mechanismen an, die in der Taxonomie auf der mittleren Ebene angesiedelt sind. Ein Mechanismus kann dabei in mehreren Diensten zum Einsatz kommen. Auf der untersten Ebene der Taxonomie befinden sich die Standards, welche die Umsetzung der Mechanismen spezifizieren. 10

21 Kapitel 2: Grundlagen In den folgenden Kapiteln werden die für die vorliegende Arbeit relevanten Sicherheitsdienste, Sicherheitsmechanismen und Sicherheitsstandards erläutert Sicherheitsdienste Identity Service Um Sicherheitsmechanismen, wie z.b. eine Authentifizierung oder Autorisierung, durchführen zu können, müssen einem System Informationen über seine Benutzer bekannt sein. Dieser Umstand macht eine Definition der Benutzer des Systems und damit eine Benutzerverwaltung erforderlich. Sollen die Benutzer zusätzlich funktional und/oder hierarchisch gegliedert werden, ist zusätzlich eine Rollen- bzw. Gruppenverwaltung notwendig. Ein Identity Service ist innerhalb eines System für die Verwaltung der Benutzer, Rollen und Gruppen und deren Beziehungen untereinander zuständig. Benutzer, Rollen und Gruppen werden im Folgenden auch allgemein als organisatorische Einheiten bezeichnet. Ein Benutzer kann dabei sowohl ein Mensch als auch ein Prozess oder eine andere Entität sein, die mit dem System kommuniziert. Die Informationen können aus verschiedenen Quellen, wie beispielsweise Dateien, Datenbanken oder LDAP-Verzeichnissen stammen, die im Folgenden allgemein als User Registries bezeichnet werden. Ein Identity Service kann zudem Informationen aus mehreren User Registries zusammenfassen und eine konsistente Sicht auf diese geben. Er bietet Schnittstellen an, über die auf die Gesamtheit aller Benutzerinformationen zugegriffen werden kann. Benutzer-, Rollen und Gruppeninformationen bestehen in der Regel aus einem eindeutigen Bezeichner (unique identifier) und weiteren Attributen, welche die jeweilige organisatorische Einheit näher charakterisieren. Bei Benutzern können dies beispielsweise -Adressen, Telefonnummern oder Rollenzugehörigkeiten sein. Ein Attribut ist dabei meist als Tripel aus Name, Typ und Wert definiert. Standardisierte Sprachen, wie z.b. SAML5 oder XACML6 definieren die Struktur solcher Attribute. Für den Austausch der Benutzer-, Rollen und Gruppeninformationen wurden im Web Service Umfeld diverse Standards wie WS-Federation7 oder SPML8 entwickelt. Diese spezifizieren einheitliche Schnittstellen für einen Identity Service. Identity Services bilden die Grundlage für andere Dienste, wie beispielsweise Authentication Services oder Authorization Services (siehe und ) Confidentiality und Integrity Service Ein Confidentiality und Integrity (C&I) Service sorgt dafür, dass die Vertraulichkeit und Integrität von Nachrichten, die mit einem System ausgetauscht werden, gewährleistet ist. Dies wird mit Hilfe von Mechanismen wie Verschlüsselung, digitalen Signaturen und digitalen Zertifikaten erreicht (siehe , , ), welche auf verschie ( ) ( ) ( ) ( ) 11

22 Kapitel 2: Grundlagen denen Schichten des OSI-Referenzmodells9 angewendet werden können. Auf Transportebene kann eine Point-to-Point Security, auf Anwendungsebene eine End-to-End Security gewährleistet werden (vgl. [Jos07]). Die beiden Arten von Sicherheit werden in den Kapiteln und ausführlich erläutert. Die durch einen C&I Service gewährleistete Sicherheit ist Voraussetzung für alle weiteren in diesem Kapitel beschriebenen Dienste Authentication Service Authentication Services überprüfen, ob ein Benutzer derjenige ist, der er vorgibt zu sein. Dies geschieht in der Regel durch die Überprüfung von Identitätsnachweisen (Credentials), die von Benutzern angegeben werden. Ein Beispiel für eine solche Überprüfung ist der Abgleich von Benutzername und Passwort. Alternativ können auch biometrische Merkmale oder digitale Signaturen und Zertifikate (siehe , ) für eine Authentifizierung verwendet werden. Um die Credentials überprüfen zu können, greift ein Authentication Service auf Daten innerhalb eines Credential Stores zurück. Ein Credential Store enthält beispielsweise die Zuordnungen von Benutzernamen zu Passwörtern oder die öffentlichen Schlüssel der Benutzer eines Systems (vgl. [Pap07], [BAB+07], [Ber08a]). Zu den Aufgaben eines Authentication Services gehört ebenfalls die Gewährleistung der Einmaligkeit (Uniqueness) von Nachrichten. Dazu können verschiedene Mechanismen wie z.b. Zeitstempel oder Nonces eingesetzt werden (vgl. [CDK05]). Die Übergabe von Credentials erfolgt innerhalb sog. Security Tokens. Ein Security Token bündelt Credentials eines Benutzers und kann zusätzlich Behauptungen (Claims) über den Benutzer enthalten. Beispiele für solche Behauptungen sind etwa: Der Benutzer ist authentifiziert Der Name des Benutzers ist Heiko Görig Der Benutzer ist ein Premiumkunde Um eine Authentifizierung durchzuführen, muss ein System die von dem zugreifenden Benutzer übergebenen Security Tokens an seinen Authentication Service weiterreichen. Der Authentication Service überprüft die darin enthaltenen Credentials und gibt eine Authentifizierungsbestätigung, üblicherweise ebenfalls in Form eines Security Tokens, zurück. In diesem Fall spricht man auch von einem Issued Token. Ein Issued Token enthält, im Vergleich zu dem ursprünglichen Security Token, oft zusätzliche Claims über den Benutzer. Da ein System seinem Authorization Service in der Regel traut, sind solche Claims mit Attributen des Benutzers gleichzusetzen. Sie stammen von Identity Services, auf die ein Authentication Service im Zuge der Authentifizierung zugreift. Innerhalb des System können sie beispielsweise zur Autorisierung des Benutzers verwendet werden (vgl. [Ber08a], [Ber08b]). Ein Authentication Service ist in der Lage, ausgestellte Security Token digital zu signieren und somit die darin enthaltenen Angaben zu beglaubigen. Ein solches beglaubigtes 9 ( ) 12

23 Kapitel 2: Grundlagen Security Token kann von anderen Authentication Services, anstelle der ursprünglichen Credentials, als Identitätsnachweis akzeptiert werden. Da der Benutzer seine Credentials nur einmal angeben muss, wird dieser Mechanismus auch als Single Sign-On (SSO) bezeichnet. In Kapitel wird SSO anhand eines Beispiels näher erläutert. Innerhalb einer Anwendung wird mit Hilfe eines Security Tokens üblicherweise ein sog. Authentication Context gebildet. Der Authentication Context kapselt die Identität des Benutzers und kann dazu verwendet werden, sich bei externen Komponenten oder anderen Anwendungen als entsprechender Benutzer zu authentifizieren. Da ein Authentication Context normalerweise auch Informationen über den Benutzer bereitstellt, wird in dieser Arbeit im Folgenden von einem Benutzerkontext gesprochen (vgl. [Pap07]). Ein Benutzerkontext wird in einer technischen Umsetzung häufig mit einem bestimmten Prozess oder Thread innerhalb einer Anwendung verknüpft. Aktionen, die in dem Prozess/Thread stattfinden, (Funktionsaufrufe, Web Service Aufrufe, etc.) werden dann im Namen des jeweiligen Benutzers ausgeführt. Da der Benutzer innerhalb des Anwendung nicht mehr authentifiziert werden muss, stellt die Anwendung einen geschützten Bereich dar. Man spricht auch von einer Protection Domain. Wenn eine Nachricht an eine zweite Anwendung geschickt wird, verlässt diese die Protection Domain der ursprünglichen Anwendung. Der Benutzerkontext des Prozesses kann nun verwendet werden, um sich bei der zweiten Anwendung zu authentifizieren. Die Existenz eines Benutzerkontext kann ebenfalls eine Voraussetzung für andere Dienste, wie z.b. den Authorization Service, sein Authorization Service Ein Authorization Service erlaubt oder verwehrt authentifizierten oder nicht authentifizierten Benutzern den Zugriff auf bestimmte Ressourcen. Er führt damit eine Zugriffskontrolle durch, die bei einer positiven Entscheidung zu einer Autorisierung des Benutzers führt. Die Entscheidung ist dabei von den Richtlinien (Policies) des Authorization Services abhängig, die aus verschiedenen Quellen wie z.b. Dateien oder Datenbanken stammen können. Die Richtlinien werden ausgewertet, sobald ein Decision Request an den Authorization Service gestellt wird. Ein Decision Request enthält üblicherweise Informationen darüber, welcher Benutzer welche Aktion auf welcher Ressource ausführen möchte. Der Authorization Service wendet die Richtlinien auf den Decision Request an und gibt das Ergebnis, die Authorization Decision, an den Aufrufer zurück. Da der Authorization Service die Entscheidung über die Zugriffsberechtigung fällt, repräsentiert er den Policy Decision Point (PDP) des Systems. Stellen, an denen Decision Requests erzeugt und an den PDP übergeben werden, werden als Policy Enforcement Points (PEP) bezeichnet. Um die Einhaltung der Richtlinien zu gewährleisten, muss ein System an den notwendigen Stellen PEPs implementieren. Häufig wird dies durch einen sog. Reference Monitor realisiert, der alle Zugriffe auf Ressourcen abfängt und eine vorherige Autorisierung veranlasst (vgl. [BAB+07], [SFH05+], [XAC05]). Für die Zugriffskontrolle können verschiedene Mechanismen wie Discretionary Access Control (DAC), Role-Based Access Control (RBAC) oder Mandatory Access Control (MAC) eingesetzt werden. Diese verwenden jeweils unterschiedliche Kriterien zur Auswertung von Zugriffsberechtigungen. Bei der DAC wird die Authorization Decision 13

24 Kapitel 2: Grundlagen beispielsweise lediglich anhand der Identität des Benutzers ( adminxy ), der auszuführenden Aktion ( write ) sowie der Identität der Ressource ( c:/config.ini ) getroffen. Wird MAC verwendet, so können hingegen noch weitere Eigenschaften des Benutzers, der Aktion oder der Ressource in die Entscheidung mit einbezogen werden. Bei der RBAC werden Rechte schließlich für Rollen statt für Benutzer definiert, so dass die Zugriffsberechtigung von den Rollenzugehörigkeiten des Benutzers abhängt ([SFH05+], [FeK92]). Es existieren mehrere Standards, welche die Struktur von Richtlinien und Berechtigungsabfragen festlegen. Ein Standard, mit dem sich sowohl DAC, als auch RBAC und MAC realisieren lassen, ist die in Kapitel beschriebene extensible Access Control Markup Language (XACML) Audit Service Audit Services speichern in sog. Audit Trails Informationen über Ereignisse, die in einem System auftreten. Dabei kann es sich etwa um sicherheitskritische Ereignisse wie die Gewährung/Ablehnung einer Autorisierung oder eine fehlgeschlagene Authentifizierung handeln. Jedes Ereignis enthält in der Regel Angaben darüber, zu welchem Zeitpunkt, für welchen Benutzer und bei welcher Aktion es aufgetreten ist. Auf diese Weise lässt sich im Nachhinein eine Ereigniskette rekonstruieren (vgl. [Pap07], [LeR00]). Ein Audit Service kann verwendet werden, um Verbindlichkeit (non-repudiation) von Nachrichten zu gewährleisten. Dazu müssen lediglich alle Nachrichten persistent in einem Audit Trail gespeichert werden. Voraussetzung ist, dass die Nachrichten über digitale Signaturen geschützt sind. Ein Eingang der Nachricht kann dann jederzeit gegenüber einer neutralen dritten Partei nachgewiesen werden. In [Pap07] wird ein solcher Dienst auch als Non-repudation Service bezeichnet. Audit Services bilden häufig die Grundlage für die Erfüllung und Einhaltung gesetzlicher und vertraglicher Regelungen (Compliance). So fordert der Sarbanes-Oxley-Act (SOX) von Unternehmen beispielsweise den lückenlosen Nachweis aller bilanzrelevanter Transaktionen. Ein Audit Service kann für die Speicherung der Transaktionsdaten sorgen und somit die Einhaltung dieser gesetzlichen Bestimmung sicherstellen. Darüber hinaus können Audit Services als Basis für viele weitere Dienste und Anwendungen verwendet werden. So kann z.b. ein automatisches Kontrollsystem implementiert werden, welches die Daten des Audit Services überwacht und laufend die Einhaltung von internen, vertraglichen oder gesetzlichen Regelungen überprüft Sicherheitsmechanismen Verschlüsselung Verschlüsselung ist die Transformation einer verständlichen Information in eine unverständliche. Diese Transformation kann durch eine inverse Transformation, die Entschlüsselung, wieder rückgängig gemacht werden. Die Entschlüsselung wird mit Hilfe eines Geheimnisses (eines Schlüssels) durchgeführt, in dessen Besitz nur dazu berechtigte Personen sind. Durch diese Personalisierung ist die Vertraulichkeit der Informatio14

25 Kapitel 2: Grundlagen nen gewährleistet. Neben der Vertraulichkeit können moderne Verschlüsselungsverfahren auch dazu eingesetzt werden, die Integrität und Authentizität von Nachrichten sicherzustellen (vgl. [CDK05]). Bei modernen Verschlüsselungsverfahren unterscheidet man zwischen zwei Klassen: den symmetrischen und den asymmetrischen Verschlüsselungsverfahren. Symmetrische Verschlüsselungsverfahren Bei symmetrischen Verschlüsselungsverfahren wird zum Verschlüsseln und Entschlüsseln von Daten derselbe Schlüssel verwendet. Beim Nachrichtenaustausch müssen also sowohl Sender als auch Empfänger im Besitz des Geheimnisses (des Schlüssels) sein. Wurde der Schlüssel nicht bereits vorher auf anderem Wege ausgetauscht, kann ein symmetrischer Schlüssel auch mit Hilfe verschiedener Schlüsselaustauschverfahren (z.b. dem Diffie-Hellman-Schlüsselaustausch) vor dem eigentlichen Nachrichtenaustausch ausgehandelt werden. Zu den am häufigsten eingesetzten symmetrischen Verschlüsselungsverfahren gehören der Data Encryption Standard (DES)10 und dessen Nachfolger, der Advanced Encryption Standard (AES)11. Asymmetrische Verschlüsselungsverfahren Asymmetrische Verschlüsselungsverfahren verwenden zur Ver- und Entschlüsselung von Daten jeweils unterschiedliche Schlüssel, die zusammen ein Schlüsselpaar bilden. Der Empfänger einer Nachricht besitzt dabei den geheimen (privaten) Schlüssel, mögliche Sender den nicht geheimen (öffentlichen) Schlüssel des Empfängers. Wenn ein Sender nun eine Nachricht mit dem öffentlichen Schlüssel verschlüsselt, ist nur der Empfänger in der Lage, diese Nachricht wieder zu entschlüsseln, da er allein im Besitz des dazu passenden, privaten Schlüssels ist. Umgekehrt können Nachrichten, die mit dem privaten Schlüssel verschlüsselt wurden, nur mit dem öffentlichen Schlüssel wieder entschlüsselt werden. Ein Vorteil gegenüber symmetrischen Verschlüsselungsverfahren ist, dass das Geheimnis (der private Schlüssel) nur dem Empfänger bekannt sein muss. Dadurch verringert sich die Anzahl der geheim zu haltenden Informationen pro Kommunikationspartner. Da öffentliche Schlüssel in der Regel frei zugänglich sind, kann jeder eine verschlüsselte Nachricht an den Empfänger schicken. Jedoch muss ein Sender bei der Verwendung eines öffentlichen Schlüssel sicherstellen, dass dieser wirklich der öffentliche Schlüssel des beabsichtigten Empfängers ist. Dies kann mit Hilfe digitaler Zertifikate erreicht werden (siehe ). Asymmetrische Verschlüsselungsverfahren sind um ein vielfaches langsamer als symmetrische Verschlüsselungsverfahren. Daher werden sie häufig lediglich zum sicheren Austausch eines temporär gültigen, symmetrischen Schlüssels (Session Key) verwendet. Da der öffentliche Schlüssel bei asymmetrischen Verschlüsselungsverfahren in der Regel für jeden zugänglich ist, werden diese auch als Public-Key-Verfahren bezeichnet ( ) ( ) 15

26 Kapitel 2: Grundlagen Ein häufig verwendetes, asymmetrisches Verschlüsselungsverfahren ist RSA12, welches 1977 von Ronald L. Rivest, Adi Shamir und Leonard Adleman entwickelt wurde. Verschlüsselung ist eine Voraussetzung für weitere Mechanismen, die in den folgenden Kapiteln beschrieben werden Digitale Signaturen Digitale Signaturen können eingesetzt werden, um die Integrität und Authentizität von Nachrichten zu gewährleisten (siehe 2.3.2). Der Sender einer Nachricht unterschreibt den Inhalt (die Nutzdaten) der Nachricht, bevor diese an den Empfänger geschickt wird. Dazu berechnet er zunächst eine Prüfsumme der zu übertragenen Nutzdaten. Die Berechnung muss dabei mit einer Einwegfunktion (z.b. MD5, SHA-1) durchgeführt werden, so dass es für Angreifer nicht möglich ist, Nutzdaten mit derselben Prüfsumme zu konstruieren. Die Prüfsumme wird anschließend mit den in beschriebenen Mechanismen verschlüsselt und an die entsprechende Nachricht angehängt. Nach Übertragung der Nachricht kann der Empfänger seinerseits die Prüfsumme der Nutzdaten berechnen und mit der empfangenen und entschlüsselten Prüfsumme vergleichen. Falls die Prüfsummen übereinstimmen, ist die Nachricht unverändert und muss zudem von der angegebenen Identität stammen, da nur sie in der Lage war, die Prüfsumme korrekt zu verschlüsseln. Falls Public-Key-Verfahren zur Verschlüsselung der Prüfsumme verwendet werden, reichen digitale Signaturen allein nicht aus, um die Integrität und Authentizität von Nachrichten zu gewährleisten: In sog. Man-in-the-middle-Angriffen könnte sich ein Angreifer zwischen Sender und Empfänger platzieren und diesen den jeweils anderen Kommunikationspartner vortäuschen. Um dies zu verhindern, können die im nächsten Kapitel beschriebenen digitalen Zertifikate eingesetzt werden Digitale Zertifikate Ein digitales Zertifikat ist ein elektronisches Dokument, das von einer Zertifizierungsstelle (Certificate Authority(CA)/Issuer) erstellt wird und eine Identität mit einem öffentlichen Schlüssel verknüpft (siehe ). Es enthält, neben den Information zu der Identität (wie z.b. Name, Adresse, etc.) und dem öffentlichen Schlüssel, mindestens noch den Namen einer Zertifizierungsstelle und eine digitale Signatur. Die digitale Signatur wird mit dem privaten Schlüssels der Zertifizierungsstelle über alle anderen Daten des Zertifikats berechnet. Dadurch kann von jedem, der im Besitz des öffentlichen Schlüssels der Zertifizierungsstelle ist, nachgewiesen werden, dass das Zertifikat von dieser ausgestellt wurde. Die Zugehörigkeit des öffentlichen Schlüssel zur Identität einer Zertifizierungsstelle kann wiederum von einer übergeordneten Zertifizierungsstelle in einem digitalen Zertifikat bestätigt werden. Auf diese Weise entsteht eine Zertifikatskette (Certificate Chain), an deren Ende sich in der Regel eine sog. Root Certificate Authority befindet, die sich ihr Zertifikat durch sog. Self-Signing selbst ausgestellt hat. Über Sperrlisten oder ähnliche Mechanismen können Zertifikate von einer Zertifizierungsstelle auch wie12 ( ) 16

27 Kapitel 2: Grundlagen der zurückgezogen werden (certificate revocation). Insgesamt wird der Aufwand für den Aufbau eines solchen Systems von Zertifikaten und Zertifizierungsstellen, welches auch als Public Key Infrastructure (PKI) bezeichnet wird, als relativ hoch angesehen. Dafür hat eine PKI jedoch auch entscheidende Vorteile. Ein System kann in einer PKI so konfiguriert werden, dass es allen Zertifikaten, die von bestimmten Zertifizierungsstellen ausgestellt wurden, vertraut. Dadurch ist es für das System nicht mehr erforderlich, alle seine Benutzer und deren Authentifizierungsinformationen zu kennen. Stattdessen kann festgelegt werden, dass jede Nachricht an das System eine digitale Signatur und das Zertifikat des Aufrufers enthalten muss. Das System kann nun mit Hilfe des öffentlichen Schlüssels der Zertifizierungsstelle zunächst das Zertifikat überprüfen. Wird dieses einer vertrauenswürdigen Zertifizierungsstelle zugeordnet, kann anschließend mit dem im Zertifikat angegebenen öffentlichen Schlüssel die digitale Signatur der Nachricht verifiziert werden. Der von der International Telecommunication Union (ITU) entwickelte X.509 Standard ist der zurzeit verbreitetste Standard für digitale Zertifikate Point-to-Point Security Bei der Transport-Layer Security findet eine Absicherung von Nachrichten auf der Transportschicht des OSI-Referenzmodells14 statt. Ein auf das Transportprotokoll aufgesetztes Verschlüsselungsprotokoll (z.b. TLS15) sorgt für eine Authentifizierung und Verschlüsselung der übertragenen Daten. Vor dem eigentlichen Versand von Nachrichten wird dabei zunächst eine sichere Verbindung aufgebaut. Dies geschieht durch den Austausch von Credentials und die Einigung auf ein Verschlüsselungsverfahren sowie die zu verwendenden Schlüssel. Anschließend werden alle Daten, die über diese Verbindung geschickt werden, mit den vereinbarten Verschlüsselungsmechanismen und Schlüsseln gesichert. Durch Anwendung der Transport-Layer Security kann eine Point-to-Point Security hergestellt werden (vgl. [Jos07]). Diese wird auf der folgenden Seite anhand von Abbildung 2.4 erläutert. 13 ( ) ( )

28 Kapitel 2: Grundlagen Abbildung 2.4: Point-to-Point Security durch Transport-Layer Security Ein Sender schickt eine Nachricht an einen Intermediary, der diese wiederum an den eigentlichen Empfänger der Nachricht, den Ultimate Receiver, weiterleitet. Die Nachricht durchläuft dabei die verschiedenen Schichten des OSI-Referenzmodells und wird von den jeweiligen Kommunikationsprotokollen verarbeitet. Da die Sicherheitsmechanismen auf der Transportschicht angewendet werden, ist die Nachricht auf allen darunter liegenden Schichten gesichert. Zwischen zwei angrenzenden Systemen, die oberhalb der Transportschicht auf die Nachricht zugreifen, (z.b. Sender und Intermediary) wird jeweils ein Security Context erzeugt. Anhand des Beispiels werden folgende Einschränkungen der Point-to-Point Security ersichtlich: Alle Intermediaries zwischen Sender und Ultimate Receiver müssen vertrauenswürdig sein und jeweils separat für die Authentizität, Integrität und Vertraulichkeit von Nachrichten sorgen. Sender von Nachrichten können sich nicht direkt beim Ultimate Receiver authentifizieren. Ein Intermediary muss dadurch evtl. Kenntnisse über die Benutzer des Ultimate Receivers haben. Der Inhalt von Nachrichten kann nicht vor Intermediaries geheim gehalten werden. Nachrichten können nur entweder ganz oder gar nicht gesichert werden. Um die oben genannten Einschränkungen zu vermeiden, wird eine End-to-End Security zwischen Sender und Ultimate Receiver benötigt. Wie diese hergestellt werden kann, ist Thema des nächsten Kapitels End-to-End Security Im Gegensatz zur Point-to-Point Security wird eine Nachricht bei der End-to-End Security auf ihrem gesamten Weg vom Sender zum Ultimate Receiver geschützt. Eine Möglichkeit zur Herstellung einer End-to-End Security ist die Verwendung von MessageLayer Security (siehe Abbildung 2.5). 18

29 Kapitel 2: Grundlagen Abbildung 2.5: End-to-End Security durch Message-Layer Security Bei der Message-Layer Security findet eine Absicherung der Nachrichten auf Anwendungsebene statt. Die gesamte Nachricht oder Teile der Nachricht werden vor der Übergabe an das Transportprotokoll verschlüsselt und signiert. Auf diese Weise können Informationen vor den Intermediaries geheim gehalten werden. Angaben zur Sicherheit, wie etwa Identitätsnachweise oder Verschlüsselungsinformationen, werden innerhalb der Nachrichten platziert und unabhängig vom zugrunde liegenden Transportprotokoll bis zum Ultimate Receiver weitergegeben. Dadurch kann sich ein Sender direkt beim Ultimate Receiver authentifizieren und zu diesem einen Security Context aufbauen. Durch die partielle Verschlüsselung ist es zudem möglich, Intermediaries Zugriff auf diejenigen Informationen zu geben, die sie zur Übermittlung und Verarbeitung der Nachricht benötigen (vgl. [Jos07], [WCL+05]). Die Standards WSS und WS-SecurityPolicy können verwendet werden, um eine Endto-End Security im Web Service Umfeld zu gewährleisten (siehe und ) Single Sign-On Als Single Sign-On (SSO) wird ein Mechanismus bezeichnet, durch den ein Benutzer nach einmaliger Anmeldung Zugriff auf die Ressourcen mehrerer Softwaresysteme hat, ohne sich separat bei diesen anmelden zu müssen. Single Sign-On kann auf verschiedene Arten realisiert werden. Abbildung 2.6 zeigt eine Variante, die auf einem Security Token Service (STS) basiert und im Folgenden beschrieben wird. Ein Client will auf Dienste zugreifen, die von zwei verschiedenen Servern bereitgestellt werden. Beide Server sind so konfiguriert, dass sie den Authentifizierungsbestätigungen des STS vertrauen. Um auf die Dienste zugreifen zu können, muss der Client daher zunächst eine Authentifizierungsbestätigung von dem STS anfordern. Dies geschieht durch eine Request Security Token (RST) Nachricht, in der der Benutzer seine Credentials (z.b. Benutzername und Passwort) an den STS schickt. Dieser überprüft die Credentials, erzeugt ein Security Token und schickt dieses in der Request Security Token Response (RSTR) wieder an den Client zurück. Das Security Token enthält Angaben (Claims) über den Benutzer, wie beispielsweise dessen Identität, zugewiesene Rollen oder Berechtigungen, die durch eine digitale Signatur des STS geschützt und beglaubigt 19

30 Kapitel 2: Grundlagen Abbildung 2.6: Single Sign-On mit einem Security Token Service (STS) sind. Durch Übergabe des Security Token, welches die Authentifizierungsbestätigung darstellt, kann der Client nun die Dienste aufrufen. Die Echtheit des Security Tokens kann von den Servern anhand der digitalen Signatur überprüft werden. Verfügt jeder Server über einen STS, spricht man auch von einem Circle of trust. Im Bereich Web Services können die Standards WS-Trust16 und SAML Token Profile17 für die Realisierung von SSO verwendet werden. WS-Trust definiert dabei den Ablauf des Nachrichtenaustauschs, das SAML Token Profile die Struktur von Security Tokens. Ein weiterer Standard der SSO unterstützt, ist Kerberos Sicherheitsstandards Web Services Security Web Services Security (WSS) ist ein Standard, der Mechanismen zum sicheren Austausch von SOAP-Nachrichten spezifiziert. Ursprünglich von IBM, Microsoft und VeriSign unter dem Namen WS-Security entwickelt, wurde der Standard 2004 von der OASIS übernommen und weiterentwickelt. Die aktuelle Version 1.1 wurde im Februar 2006 veröffentlicht. Mit WSS kann die in Kapitel beschriebene End-to-End Security realisiert werden. 16 ( ) ( ) 18 ( ) 17 20

31 Kapitel 2: Grundlagen Der Standard umfasst mehrere Dokumente, wobei die WS-Security Core Specification die Kernaspekte des Standards enthält. In ihr wird spezifiziert, wie die Vertraulichkeit und Integrität von SOAP-Nachrichten mit Hilfe von Verschlüsselung, digitalen Signaturen und der Übertragung von Security Tokens gewährleistet werden kann (vgl. [WSS06]). Der Standard definiert die zusätzlichen Elemente, die dazu innerhalb einer SOAP-Nachricht verwendet werden müssen. Die Verschlüsselung und Signatur von XML-Elementen wird in den separaten Standards XML Encryption Syntax and Processing19 und XML Signature Syntax and Processing20 beschrieben. Die verschiedenen Security Tokens werden ebenfalls in eigenen Standards, wie beispielsweise dem Username Token Profile 1.1 [WSU06] oder dem X.509 Certificate Token Profile 1.121, spezifiziert [...] <soap:header xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wsse=" /01/oasis wss-wssecurity-secext-1.0.xsd" xmlns:wsu=" /01/oasis wss-wssecurity-utility-1.0.xsd"> <wsse:security soap:mustunderstand="1"> <wsse:usernametoken wsu:id="usernametoken "> <wsse:username>max Mustermann</wsse:Username> <wsse:password Type="...wss-username-token-profile-1.1#PasswordDigest"> wmt4xfhnwtjsh3jzgizakykwqna= </wsse:password> <wsse:nonce>q3npynwedr/g6xkz4ojo3a==</wsse:nonce> <wsu:created> t14:24:16.234z</wsu:created> </wsse:usernametoken> </wsse:security> </soap:header> [...] Listing 2.2: SOAP Header mit Benutzername und Passwort Listing 2.2 zeigt einen SOAP-Header, der ein WSS konformes Security-Element mit einem UsernameToken-Element enthält (Zeile 6). Das UsernameToken entspricht der Spezifikation aus [WSU06] und beinhaltet, neben einem Benutzernamen und einem Password, ebenso eine Nonce und einen Zeitstempel (Zeile 7-12). In diesem Fall ist die Nachricht weder verschlüsselt noch signiert. Damit ein Service Requestor Nachrichten erzeugen kann, die von dem Service Provider akzeptiert werden, müssen ihm die Sicherheitsanforderungen des aufzurufenden Web Services bekannt gemacht werden. Der Standard WS-SecurityPolicy bietet eine Möglichkeit, wie Sicherheitsanforderungen maschinenlesbar beschrieben werden können WS-SecurityPolicy WS-Policy stellt einen Rahmen bereit, um Merkmale, Anforderungen und Einschränkungen eines Web Services durch Policy Assertions auszudrücken (siehe 2.2.1). Der Standard WS-SecurityPolicy definiert solche Policy Assertions bezüglich der in WSS, WS-Trust und WS-SecureConversation22 bereitgestellten Sicherheitsmechanismen. Poli19 ( ) ( ) 21 ( ) 22 ( ) 20 21

32 Kapitel 2: Grundlagen cies, die aus diesen Policy Assertions aufgebaut sind, beschreiben somit Sicherheitsanforderungen und Sicherheitseinschränkungen von Web Services. Solche Policies werden im Folgenden als Security Policies bezeichnet (vgl. [WSP07]). Durch eine Security Policy kann beispielsweise festgelegt werden, auf welche Art (symmetrisch/asymmetrisch) und mit welchen Algorithmen (DES/AES/RSA) Nachrichten bei einem Nachrichtenaustausch verschlüsselt und signiert werden müssen. Zudem ist es möglich, unterstützende Merkmale, sog. Supporting Tokens, innerhalb von Nachrichten vorauszusetzen. Dies kann beispielsweise ein UsernameToken oder ein sonstiges Security Token sein, mit dem der Empfänger einer Nachricht in der Lage ist, den Sender zu authentifizieren. Eine Security Policy legt zudem fest, wie solche Supporting Tokens abgesichert werden müssen. Security Policies können an verschiedene Policy Subjects, wie z.b. Endpunkte oder Operationen, innerhalb einer WSDL Definition angehängt werden. Das Policy Subject bestimmt dabei die Granularität der Sicherheit: Wird eine Security Policy beispielsweise einer Operation angehängt, so gilt die Security Policy nur für diese eine Operation. Ist die Security Policy dagegen einem Endpunkt zugeordnet, so gilt sie für alle Operationen des Endpunktes. In [Bet08] werden diese Granularitäten als Operation-Level Security bzw. Endpoint-Level Security bezeichnet. Durch die Angabe der Security Policies innerhalb von WSDL-Dateien sind Aufrufer in der Lage, Nachrichten zu erzeugen, die von dem jeweiligen Web Service akzeptiert werden. So kann ein Service Requestor bei Web Service Aufrufen die geltende Security Policy auslesen und entsprechende Änderungen an der SOAP-Nachricht, wie z.b. eine Verschlüsselung, vornehmen. Umgekehrt kann die Security Policy auch vom Service Provider verwendet werden, um eingehende SOAP-Nachrichten zu entschlüsseln und enthaltene Signaturen oder Supporting Tokens zu überprüfen. WS-SecurityPolicy ist somit auch als Konfigurationssprache einsetzbar (vgl. [Bet08]). Dies wird anhand von Listing 2.3 erläutert. 1 <wsp:policy xmlns:wsp="http://www.w3.org/ns/ws-policy" 2 xmlns="...docs.oasis-open.org/ws-sx/ws-securitypolicy/200702"> 3 <wsp:exactlyone> 4 <wsp:all> 5 <SupportingTokens> 6 <wsp:policy> 7 <UsernameToken IncludeToken=".../AlwaysToRecipient"> 8 <wsp:policy> 9 <HashPassword /> 10 <WssUsernameToken11 /> 11 </wsp:policy> 12 </UsernameToken> 13 </wsp:policy> 14 </SupportingTokens> 15 </wsp:all> 16 </wsp:exactlyone> 17 </wsp:policy> Listing 2.3: Security Policy für passwortgeschützte Web Services Das Element SupportingTokens definiert alle unterstützenden Merkmale, die innerhalb des Nachrichtenaustauschs verwendet werden. Eines dieser Merkmale ist ein UsernameToken-Element, das in jede Nachricht, die an den Empfänger geht (siehe Attribut In22

33 Kapitel 2: Grundlagen cludetoken, Zeile 7), eingefügt werden muss. Das Element HashPassword legt fest, dass das UsernameToken-Element ein Passwort, einen Zeitstempel und eine Nonce beinhalten muss. Das WssUsernameToken11-Element sagt aus, dass das UsernameToken-Element so verwendet werden soll, wie es der Standard UsernameToken Profile 1.1 [WSU06] vorschreibt. Dort ist beispielsweise festgelegt, dass der Hashwert des Passworts aus der Konkatenation von Passwort, Zeitstempel und Nonce mit Hilfe des SHA-123 Algorithmus berechnet wird. Dem Service Requestor wird somit genau vorgegeben, wie er eine gültige Nachricht zu erzeugen hat. Weitere benötigte Informationen, wie z.b. den Benutzernamen und das Passwort, kann der Service Requestor beispielsweise durch eine Eingabemaske vom Benutzer abfragen. Wird eine Nachricht an den Service Provider geschickt, verwendet dieser die Angaben innerhalb der Policy zur Überprüfung der Nachricht. Er überprüft, ob ein UsernameToken in der Nachricht vorhanden ist und, wenn ja, ob die darin enthaltenen Angaben (Passwort, Zeitstempel, Nonce) gültig sind XACML Die Extensible Access Control Markup Language (XACML), ein weiterer Standard der OASIS, definiert eine XML-basierte Sprache mit der Richtlinien zur Zugriffskontrolle formuliert werden können. Zudem legt der Standard fest, wie die Abfrage von Zugriffsberechtigungen und die Auswertung der Richtlinien zu erfolgen hat. XACML kann zur Umsetzung von DAC, MAC und RBAC verwendet werden. Für die RBAC wurde hierbei zusätzlich dass XACML Profile for Role Based Access Control24 spezifiziert. Aktuell befindet sich XACML in der Version 2.0, die im Februar 2005 veröffentlicht wurde ([XAC05]). Eine Richtlinie (Policy) besteht in der XACML aus einem Ziel (Target), einer beliebigen Anzahl an Regeln (Rules) und einem Algorithmus zur Kombination dieser Regeln (Rule-combining Algorithm). Das Ziel spezifiziert eine Menge an Subjekten, Aktionen und Ressourcen, für die die Richtlinie gedacht ist. Eine Regel enthält ebenfalls ein Ziel, sowie eine Bedingung (Condition) und eine Auswirkung (Effect). Das Ziel legt die Menge an Subjekten, Aktionen und Ressourcen fest, auf die die Regel angewendet werden soll. Die Bedingung beschreibt einen booleschen Ausdruck, der zur Auswertung der Regel verwendet wird. Der Effect legt fest welches Ergebnis zurückgegeben wird, falls die Bedingung der Regel erfüllt ist. Die einzig möglichen Werte sind hierbei Permit und Deny. Der Rule-combining Algorithmus definiert schließlich, wie die Ergebnisse der verschiedenen Regeln einer Richtlinie miteinander kombiniert werden. Ist beispielsweise der Algorithmus Permit-Overrides festgelegt, liefert die Richtlinie ein Permit zurück, wenn mindestens eine ihrer Regeln zu einem Permit ausgewertet wurde. Die Abfrage von Zugriffsberechtigungen erfolgt durch sog. Decision Requests. In einem Decision Request ist angegeben, welches Subjekt welche Aktion auf welcher Ressource durchführen will. Subjekt, Aktion und Ressource werden dabei jeweils über Attribute näher spezifiziert. Ein Decision Requests muss an jedem Policy Enforcement Point (PEP) eines Systems erzeugt und an den Policy Decision Point (PDP) übergeben wer23 24 US Secure Hash Algorithm 1, ( ) ( ) 23

34 Kapitel 2: Grundlagen den (siehe ). Der PDP verwendet die im Decision Context angegebenen Attribute zur Ermittlung und Auswertung der geltenden Richtlinien. Das Ergebnis der Auswertung wird in einer sog. Authorization Decision zurückgegeben. Die Authorization Decision kann einen der folgenden vier Werte annehmen: Permit: Das Subjekt darf die Aktion auf der Ressource ausführen Deny: Das Subjekt darf die Aktion auf der Ressource nicht ausführen Indeterminate: Es gibt widersprüchliche Aussagen über die Berechtigung Not Applicable: Es gibt keine Aussagen über die Berechtigung Zum einfacheren Verständnis werden die beschriebenen Konstrukte nun anhand eines Beispiels verdeutlicht. Listing 2.4 zeigt eine in XACML formulierte Richtlinie. 1 [...] 2 <Policy xmlns="urn:oasis:names:tc:xacml:2.0:context" 3 PolicyId="example:MyPolicy" 4 RuleCombiningAlgId="...rule-combining-algorithm:deny-overrides"> 5 <Target> 6 <Subjects><AnySubject/></Subjects> 7 <Resources><AnyResource/></Resources> 8 <Actions><AnyAction/></Actions> 9 </Target> 10 <Rule RuleId="example:MyRule" Effect="Permit"> 11 <Target> 12 <Subjects><AnySubject/></Subjects> 13 <Resources><AnyResource/></Resources> 14 <Actions> 15 <Action MatchId="...function:string-equal"> 16 <AttributeValue DataType="...#string">write</AttributeValue> 17 <ActionAttributeDesignator AttributeId="example:actionid" 18 DataType="http://www.w3.org/2001/XMLSchema#string"/> 19 </Action> 20 </Actions> 21 </Target> 22 <Condition FunctionId="...function:string-is-in> 23 <AttributeValue DataType="...#string">admin</AttributeValue> 24 <SubjectAttributeDesignator AttributeId="example:role" 25 DataType="http://www.w3.org/2001/XMLSchema#string"/> 26 </Condition> 27 </Rule> 28 </Policy> Listing 2.4: Beispiel einer XACML Policy In den Zeilen 6-8 wird das Ziel der Richtlinie angegeben. In diesem Fall soll die Richtlinie auf beliebige Subjekte, Ressourcen und Aktionen angewendet werden (AnySubject, AnyRessource, AnyAction). Die Richtlinie enthält genau eine Regel, die im Falle einer positiven Auswertung als Ergebnis den Wert Permit zurück gibt (Zeile 10). Die Regel kann ebenfalls auf beliebige Subjekte und Ressourcen, jedoch nur auf bestimmte Aktionen angewendet werden. Die Aktionen müssen über ein Attribut mit dem Bezeichner example:actionid verfügen (ActionAttributeDesignator, Zeile 17+18). In Zeile 15 und 16 wird festgelegt, dass der Wert dieses Attributs write sein muss. Die Bedingung der Richtlinie wird in den Zeilen definiert. Sie ist erfüllt, falls das Subjekt ein Attribut mit dem Bezeichner example:ruleid und dem Wert admin besitzt. Zusammenge- 24

35 Kapitel 2: Grundlagen 1 [...] 2 <Request xmlns="urn:oasis:names:tc:xacml:2.0:context" 3 <Subject> 4 <Attribute AttributeId="example:subjectid" 5 DataType="http://www.w3.org/2001/XMLSchema#string" 6 <AttributeValue>horst</AttributeValue> 7 </Attribute> 8 <Attribute AttributeId="example:role" 9 DataType="http://www.w3.org/2001/XMLSchema#string" 10 <AttributeValue>employee</AttributeValue> 11 </Attribute> 12 <Attribute AttributeId="example:role" 13 DataType="http://www.w3.org/2001/XMLSchema#string" 14 <AttributeValue>admin</AttributeValue> 15 </Attribute> 16 </Subject> 17 <Resource> 18 <Attribute AttributeId="example:filepath" 19 DataType="http://www.w3.org/2001/XMLSchema#anyUri" 20 <AttributeValue>/de/bosch/admin/config/</AttributeValue> 21 </Attribute> 22 </Resource> 23 <Action> 24 <Attribute AttributeId="example:actionid" 25 DataType="http://www.w3.org/2001/XMLSchema#string" 26 <AttributeValue>write</AttributeValue> 27 </Attribute> 28 </Action> 29 </Request> Listing 2.5: Beispiel eines XACML Decision Requests fasst legt die Richtlinie also fest, dass Administratoren Schreibzugriff auf alle Ressourcen des Systems gewährt werden soll. Listing 2.5 zeigt einen Decision Request, der auf die Richtlinie aus Listing 2.4 angewendet werden könnte. Der Decision Request fragt ab, ob das Subjekt horst die Aktion write auf der Ressource /de/bosch/admin/config/ ausführen darf. Über zwei weitere Attribute wird das Subjekt zudem als Inhaber der Rollen employee und admin ausgewiesen (Zeile 8-15). Die oben beschriebene Richtlinie würde somit für diesen Decision Request das Ergebnis Permit zurück liefern. Wäre in dem Decision Request die Aktion read statt write angegeben, wäre das Ergebnis der Auswertung Not Applicable, da die Regel der Richtlinie nicht für diese Aktion bestimmt ist. Würde hingegen das Attribut fehlen, welches das Subjekt als Administrator ausweist, wäre das Ergebnis ein Permit. Die Erläuterungen dieses Kapitels decken nur einen kleinen Teil des XACML-Standards ab. Weitere Funktionalitäten und Beispiele können der Spezifikation ([XAC05]) entnommen werden. 25

36

37 Kapitel 3: Sicherheit in BPEL Engines Kapitel 3 Sicherheit in BPEL Engines In Kapitel wurden die Sicherheitsanforderungen ermittelt, die allgemein in verteilten Softwareumgebungen bestehen können. Ein BPEL Prozess kann als Komponente einer verteilten Softwareumgebung angesehen werden. Wenn man einen BPEL Prozess absichern will, muss man daher zunächst wissen, wie dieser mit anderen Komponenten (Web Services, Clients, anderen Prozessen) kommuniziert. Kapitel 3.1 beschreibt das Konzept und den Ablauf dieser Kommunikation. Anschließend werden in 3.2, anhand eines Beispielprozesses, diejenigen Stellen eines BPEL Prozesses identifiziert, an denen die Anwendung von Sicherheitsmechanismen notwendig sein kann. In den darauf folgenden Kapiteln wird diskutiert, wie die Sicherheitsmechanismen an den identifizierten Stellen angewendet werden können. Dabei werden zum einen Lösungen vorgestellt, die auf bestehende Mittel zurückgreifen. Zum anderen werden neue Lösungen entwickelt, die mitunter Erweiterungen an BPEL bzw. der BPEL Engine erforderlich machen. Kann mit verschiedenen Lösungen dasselbe Ergebnis erzielt werden, werden jeweils deren Vor- und Nachteile ermittelt. Dieses Kapitel setzt Kenntnisse der Standards BPEL und BPMN voraus ([BPEL07], [OMG09]). 3.1 Kommunikation mit BPEL Prozessen Ein BPEL Prozess kommuniziert über sog. Partnerlinks mit der Außenwelt. Ein Partnerlink kann als typisierter Nachrichtenkanal (channel) angesehen werden, der einen Prozess mit einem Partner verbindet. Prozess und Partner werden in einem Nachrichtenkanal unterschiedliche Rollen zugewiesen. Jede Rolle ist wiederum mit einer abstrakten WSDL Schnittstelle (siehe 2.2) assoziiert, welche die Inhaber der Rolle implementieren und über einen Endpunkt bereitstellen (vgl. [WCL+05]). Die Endpunkte eines Partnerlinks werden in der Regel nicht im BPEL Prozess, sondern über externe Mechanismen (z.b. einen Deployment Descriptor) definiert. Dadurch wird eine Entkopplung der Geschäftsprozessdefinition von den konkret verwendeten Endpunkten erreicht. Die Endpunkte können somit ohne Änderungen an der Definition des BPEL Prozesses ausgetauscht werden. 27

38 Kapitel 3: Sicherheit in BPEL Engines Falls einem BPEL Prozess in einem Partnerlink eine Rolle zugewiesen ist, sollte er die Operationen der entsprechenden WSDL Schnittstelle implementieren. Eine solche Implementierung wird durch BPEL Aktivitäten ausgedrückt: Die Aktivitäten receive, onmessage und onevent, sog. Inbound Message Activities (IMA), referenzieren WSDL Operationen und markieren die Punkte im Prozess, an denen die entsprechenden Operationen von einem Partner aufgerufen werden können. Stellt eine IMA die Startaktivität eines Prozesses dar, muss ihr zusätzlich das Attribut createinstance= yes zugewiesen werden25. Die BPEL Engine wird dadurch angewiesen, bei entsprechenden Aufrufen neue Instanzen des Prozesses zu erzeugen. Verfügt die Operation einer IMA über einen Rückgabewert, so sollte der Prozess ebenfalls eine, der IMA zugeordnete, reply-aktivität enthalten. Die reply Aktivität markiert analog die Stelle, an der das Ergebnis der Operation zurückgegeben wird. Abbildung 3.1: Darstellung eines BPEL Prozesses In Abbildung 3.1 ist dem Prozess SampleProcess beispielsweise die Rolle Provider des Partnerlinks ClientLink zugewiesen. Die Rolle Provider ist mit einer Schnittstelle assoziiert, die lediglich die Operation call enthält. In der Prozessdefinition wird der Startaktivität Receive diese Operation zugewiesen. Sie repräsentiert damit den Einstiegspunkt der Operation call". Das Ergebnis der Operation wird in der Aktivität Reply zurückgegeben. Der dazwischenliegende BPEL Code enthält die Geschäftslogik des Prozesses. Diese besteht lediglich aus dem Aufruf einer Operation, die von einem Partner des Prozesses bereitgestellt wird. Solche Aufrufe werden in BPEL durch invoke-aktivitäten ausgedrückt. Eine invoke-aktivität referenziert hierbei wiederum eine WSDL Operation, diesmal jedoch aus der Schnittstelle des Partners. In dem Prozess aus Abbildung 3.1 ist beispielsweise einem Partner des Prozesses über den Partnerlink ServiceLink gleichfalls die Rolle Provider zugewiesen. Diesmal implementiert jedoch nicht der Prozess die Operation call, sondern der Partner. Die Aktivität Invo25 Gilt nur für die receive und die pick Aktivität (Die pick Aktivität bündelt mehrere onmessage Aktivitäten) 28

39 Kapitel 3: Sicherheit in BPEL Engines ke verweist auf diese Operation und sorgt bei der Ausführung des Prozesses entsprechend für einen Aufruf der Operation. Der gezeigte Prozess implementiert somit einen einfachen Router, der Nachrichten eines Clients entgegen nimmt, an einen Dienst weiterleitet und das Ergebnis wieder an den Client zurück gibt. Die Bereitstellung und der Aufruf von Endpunkten eines BPEL Prozesses ist üblicherweise kein integraler Bestandteil einer BPEL Engine. Stattdessen ist eine BPEL Engine, wie z.b. die Apache ODE Engine, meist in eine Kommunikationsinfrastruktur eingebettet. Dies kann beispielsweise ein ESB, eine Service Component26 oder eine sonstige Komponente sein, die Web Services bereitstellen und aufrufen kann. Diese Komponente bildet die Kommunikationsschicht und wird im folgenden als Middleware bezeichnet. Sie ist abzugrenzen von der Middleware, die durch die BPEL Engine selbst realisiert wird ([LeR00]). Die BPEL Engine ist auf einer höheren Schicht anzusiedeln, da sie auf Funktionen der Kommunikationsschicht zugreift, umgekehrt jedoch keine Abhängigkeit besteht. Einige BPEL Engines, wie z.b. die Apache ODE, bieten die Möglichkeit an, die zugrunde liegende Middleware auszutauschen. Die Middleware wird selbst wiederum von einer Laufzeitumgebung, wie z.b. einem Application- oder Webserver, bereitgestellt und baut auf deren Funktionen auf. Dazu gehört etwa der Empfang und Versand von Nachrichten über das HTTP-Protokoll. Nachrichten, die zu und von einer Prozessinstanz gesendet werden, unterliegen somit einem mehrstufigen Verarbeitungsprozess. Dieser wird in Abbildung 3.2 dargestellt und im Folgenden beschrieben. Abbildung 3.2: Verarbeitungsprozess von Nachrichten Der Server ist mit einem Netzwerk verbunden und wartet auf Nachrichten. Sobald eine Nachricht eintrifft, überprüft der Server, ob sich eine seiner Komponenten für den Nachrichtenaufruf registriert hat. Ist dies der Fall, wird die Nachricht an die jeweilige Komponente, in diesem Fall die Middleware, weitergegeben. Die Middleware verarbeitet die Nachricht entsprechend ihrer Einstellungen und ermittelt den Endpunkt, für den die Nachricht bestimmt ist. Ist der Endpunkt Teil eines Partnerlinks, gelangt die Nachricht schließlich zu der BPEL Engine. Die BPEL Engine identifiziert durch den Korrelationsprozess ([BPEL07]) diejenige IMA innerhalb einer Prozessinstanz, für welche die Nachricht bestimmt ist. Anschließend werden die Nutzdaten der Nachricht der Eingabevariablen dieser Aktivität zugewiesen und die Prozessinstanz ausgeführt. Die mehrschichtige Systemarchitektur ermöglicht die Gewährleistung von Nachrichtensicherheit auf verschiedenen Ebenen des Nachrichtenaustauschs. Beispielsweise kann bereits durch den Webserver eine Authentifizierung und Autorisierung von Nachrichten durchgeführt werden. Nicht-autorisierte Nachrichten werden in diesem Fall gar nicht 26 Eine Service Component ist Bestandteil einer Service Component Architecture (SCA). Informationen zum Konzept der SCA können der Seite der Open Service Oriented Architecture Collaboration entnommen werden: ( ) 29

40 Kapitel 3: Sicherheit in BPEL Engines erst an die Middleware weitergegeben. Alternativ können Sicherheitsmechanismen auch von der Middleware oder der BPEL Engine implementiert werden. Um herauszufinden, an welchen Stelle eines Prozesses Sicherheitsmechanismen erforderlich sind und auf welchen Ebenen der Systemarchitektur diese implementiert werden können, wird im nächsten Kapitel ein Beispielprozess konstruiert. 3.2 Beispielprozess Das Szenario des Beispielprozesses befasst sich mit der automatisierten Beschaffung von Arbeitsmaterialien innerhalb eines Unternehmens. Abbildung 3.3 zeigt das Modell des Geschäftsprozesses in BPMN (siehe [OMG09]). In spitzen Klammern sind dabei zusätzlich die im vorherigen Kapitel erwähnten und für den Nachrichtenaustausch relevanten BPEL Aktivitäten angegeben. Nachrichten, welche die Schichten Eingehend und Ausgehend passieren, unterliegen jeweils dem in Abbildung 3.2 gezeigten Verarbeitungsprozess. Abbildung 3.3: BPMN-Modell des Beispielprozesses Das Modell, wie es abgebildet ist, macht noch keine Aussagen zu den Sicherheitsanforderungen des Prozesses. Diese werden nun anhand der textuellen Beschreibung des Prozesses ermittelt und anschließend in einem erweiterten BPMN-Modell visualisiert. Die Einkaufsabteilung eines Unternehmens will für die Mitarbeiter des Unternehmens einen Geschäftsprozess zur Verfügung stellen, über den sie Arbeitsmaterialien bestellen können. Dabei gibt es die Einschränkung, dass nur interne Mitarbeiter zu solchen Bestellungen berechtigt sind. Um dies zu überprüfen, kann auf die Mitarbeiterdatenbank des Unternehmens zugegriffen werden. Hier ist für jeden Mitarbeiter ein eindeutiger Be30

41 Kapitel 3: Sicherheit in BPEL Engines nutzername und ein geheimes Passwort hinterlegt, über welche er seine Identität nachweisen kann. Zusätzliche Eigenschaften, wie z.b. Standort und Abteilung der Mitarbeiter sind ebenfalls gespeichert. Außerdem enthält die Mitarbeiterdatenbank eine Zuweisung aller Mitarbeiter zu den Rollen, die sie im Rahmen ihrer Arbeit einnehmen (z.b. Einkäufer, Interner Mitarbeiter, Abteilungsleiter etc.). Sobald eine Bestellung in der Einkaufsabteilung eingeht, wird zunächst der günstigste Lieferant für die Bestellung ermittelt. Alle Lieferanten stellen hierzu Web Services zur Verfügung, die eine standardisierte Schnittstelle implementieren. Über diese Schnittstelle kann von jedem Lieferanten der Preis für eine Bestellung abgefragt werden. Um Industriespionage vorzubeugen, sind alle Bestellungen vertraulich zu behandeln und müssen daher mit dem öffentlichen Schlüssel des Lieferanten verschlüsselt werden. Eine Authentifizierung beim Lieferanten ist für die Preisabfrage nicht notwendig. Bevor eine Bestellung ausgeführt wird, muss diese zunächst von dem für die Abteilung des Bestellers zuständigen Einkäufer genehmigt werden. Davon ausgenommen sollen Bestellungen sein, die von Abteilungsleitern getätigt wurden und unter einem Volumen von 100 liegen. Alle anderen Bestellungen können alternativ auch abgelehnt oder von dem Besteller zurückgezogen werden. Falls eine Bestellung genehmigt wurde, sollen die angeforderten Arbeitsmaterialien automatisch bei dem günstigsten verfügbaren Lieferanten bestellt werden. Um eine Bestellung vertraglich abzusichern, muss die entsprechende Nachricht digital signiert werden. Die digitale Signatur soll dabei im Namen des Verantwortlichen der Bestellung ausgeführt werden. Die Einkaufsabteilung hat dazu für alle Einkäufer und Abteilungsleiter private Schlüssel und dazugehörige digitale Zertifikate erstellt. Da die Zertifikate von der Zertifizierungsstelle der Einkaufsabteilung signiert sind, werden sie von der Lieferanten anerkannt. Wie bei der Preisabfrage müssen die Nachrichten zusätzlich mit dem öffentlichen Schlüssel des Lieferanten verschlüsselt werden. Der Lieferant gibt als Bestätigung eine signierte Auftragsbestätigung zurück. Abbildung 3.4 zeigt auf der folgenden Seite nochmals den Beispielprozess, diesmal jedoch ergänzt um die in der Beschreibung genannten Sicherheitsanforderungen. 31

42 Kapitel 3: Sicherheit in BPEL Engines Abbildung 3.4: BPMN-Modell des Beispielprozesses mit Sicherheitsanforderungen Sowohl die ein- als auch die ausgehende Kommunikation des Beispielprozesses muss abgesichert werden. Bei der eingehenden Kommunikation gehört dazu, neben der Verschlüsselung, auch die Authentifizierung und Autorisierung empfangener Nachrichten. Benutzerinformationen über die Sender bestimmter eingehender Nachrichten müssen gespeichert werden, da sie für die Ausführung späterer Aktivitäten benötigt werden. So erfordert etwa die Autorisierung innerhalb des Prozesses einen Zugriff auf die Rollen des Urhebers der Bestellung. Ähnlich verhält es sich mit der Bestellungsabgabe beim Lieferanten. Hier muss, abhängig von der genehmigenden Person einer Bestellung, eine unterschiedliche Signatur der ausgehenden Nachricht erfolgen. Um Revisions- und Vertragssicherheit zu garantieren, müssen Nachrichten und Informationen über die Sender der Nachrichten persistent gespeichert werden. Die erhobenen Anforderungen decken sich im Wesentlichen mit den Anforderungen, welche die Workflow Management Coalition in [WFM98] ermittelt hat. In den folgenden Kapiteln wird erörtert, wie die verschiedenen Sicherheitsanforderungen erfüllt werden können. Die Reihenfolge orientiert sich dabei an dem Ablauf des Beispielprozesses. 32

43 Kapitel 3: Sicherheit in BPEL Engines 3.3 Absicherung der eingehenden Kommunikation Zunächst muss sichergestellt werden, dass alle eingehenden Nachrichten des Beispielprozesses eine Authentifizierung ihres Absenders erlauben. Wäre dies nicht der Fall, könnte jeder, der Zugang zu dem Web Service des Geschäftsprozesses hat, beliebige Bestellungen aufgeben, zurückziehen oder darüber entscheiden. Zudem müssen die Nachrichten verschlüsselt sein, da sie sonst abgefangen und darin enthaltene Passwörter ausgelesen werden könnten. Die genannten Sicherheitsanforderungen können auf verschiedenen Ebenen des Systems umgesetzt werden (siehe 3.1). Zwei dieser Umsetzungen werden im Folgenden betrachtet. Da bei der ersten Umsetzung die Authentifizierung Teil der Ausführung einer Prozessinstanz ist, wird diese Umsetzung als Instance Authentication bezeichnet. Der zweiten Umsetzung wird analog die Bezeichnung Middleware Authentication zugewiesen. Beide Umsetzungen stehen repräsentativ für weitere Umsetzungsalternativen, die lediglich Modifikationen der vorgestellten Lösungen darstellen und daher im Wesentlichen über dieselben Eigenschaften verfügen Instance Authentication Beschreibung Zur Verschlüsselung der übertragenen Daten wird ein sicheres Netzwerkprotokoll (wie z.b. HTTPS) verwendet. Wie in Kapitel erläutert, ist hierdurch eine Point-toPoint Sicherheit zwischen Client und Server gewährleistet. In der Regel erfolgt dabei jedoch nur eine Authentifizierung des Servers beim Client. Damit umgekehrt der Aufrufer des Prozesses authentifiziert werden kann, fügt der Client bei Aufrufen des Prozesses entsprechende Credentials in die Nutzdaten der Nachricht ein. Im Prozess wird anschließend überprüft, ob die übergebenen Angaben korrekt sind. Dies kann auf verschiedene Arten, wie etwa durch den Aufruf eines Authentication Services, erfolgen (siehe ). Falls die Authentifizierung fehlschlägt wird eine entsprechende Meldung zurückgegeben und eine Fehlerbehandlung durchgeführt. Auf der folgenden Seite wird anhand von Listing 3.1 gezeigt, wie eine Umsetzung in BPEL aussehen könnte. 33

44 Kapitel 3: Sicherheit in BPEL Engines 1 <process xmlns=".../process/executable" 2 xmlns:as="http://localhost/org/sales/authenticationservice"> 3 [...] 4 <variables> 5 <variable name="orderrequest" messagetype="tns:order"/> 6 <variable name="authrequest" messagetype="as:authrequest"/> 7 <variable name="authresponse" messagetype="as:authresponse"/> 8 [...] 9 </variables> 10 <sequence> 11 <receive name="startorder" createinstance="yes" 12 partnerlink="salespartnerlink" operation="startorder" 13 inputvariable="orderrequest"/> 14 <assign> 15 <copy> 16 <from>$orderrequest.data/username</from> 17 <to>$authrequest.data/username</to> 18 </copy> 19 <copy> 20 <from>$orderrequest.data/password</from> 21 <to>$authrequest.data/password</to> 22 </copy> 23 </assign> 24 <invoke partnerlink="authenticationpl" operation="authenticate" 25 inputvariable="authrequest" outputvariable="authresponse"/> 26 <if> 27 <condition>$authresponse.result/text()!= 'true'<condition> 28 <reply partnerlink="mypl" operation="startorder" 29 variable="authresponse" faultname="as:authfault"/> 30 <throw faultname="as:authfault"/> 31 </if> 32 [...] 33 </sequence> 34 </process> Listing 3.1: Authentifizierung innerhalb des Workflows Zusätzlich zu der Variablen für die eingehende Nachricht werden zwei Variablen für den Aufruf bzw. die Antwort des Authentication Service deklariert (Zeile 6+7). Sobald eine Nachricht eintrifft, werden durch ein assign der Benutzername und das Passwort in die Variable authrequest kopiert (Zeile 14-23). Anschließend wird der Authentication Service mit authrequest als Eingabevariable und authresponse als Ausgabevariable aufgerufen (invoke, Zeile 24+25). Falls der Benutzer nicht authentifiziert werden kann, wird eine Fehlermeldung an den Benutzer zurückgegeben (reply, Zeile 28+29). Anschließend die Fehlerbehandlung ausgelöst, die schließlich zum Abbruch des Prozesses führt (throw, Zeile 30). Bewertung Vorteile Im Prozess kann über Variablen auf die Identität von Aufrufern zugegriffen werden. Auf fehlgeschlagene Authentifizierungen kann innerhalb des Prozesses reagiert werden. Da die Authentifizierung über einen herkömmlichen Web Service Aufruf durchgeführt wird, sind keine Erweiterungen an der BPEL Engine erforderlich. 34

45 Kapitel 3: Sicherheit in BPEL Engines Aufrufe einer Prozessinstanz können durch entsprechende Korrelation-Sets nur einem bestimmten Benutzers erlaubt werden. Nachteile In der Prozessdefinition wird (funktionale) Geschäftslogik mit (nicht-funktionaler) Sicherheitslogik vermischt. Bei Änderungen der Sicherheitslogik muss die Prozessdefinition angepasst werden. Die Nutzdaten der Nachrichten enthalten nicht nur funktionale, sondern auch nichtfunktionale Sicherheitsinformationen. Die Prozessdefinition wird erheblich umfangreicher und damit schwieriger les- und wartbar. Es wird viel redundanter Code erzeugt, da der Code-Abschnitt aus Listing 3.1 an allen Stellen eingefügt werden müssen, an denen Authentifizierung benötigt wird. Da die Verschlüsselung auf Transportebene durchgeführt wird, ist nur eine Point-toPoint Security gewährleistet (siehe ). Es werden auch Prozessinstanzen erzeugt, wenn ein Benutzer nicht authentifiziert werden kann. Alle IMA, die keine Startaktivitäten sind, müssen innerhalb von Schleifen ausgeführt werden. Falls nicht, führt eine fehlgeschlagene Authentifizierung automatisch zum Abbruch der Prozessinstanz. Um die Menge an Code zu reduzieren, könnte eine Authentifizierung alternativ innerhalb einer speziellen Extension Activity durchgeführt werden. Eine BPEL Engine müsste dazu entsprechend erweitert werden. Dies würde jedoch wiederum die Prozessdefinition von der modifizierten BPEL Engine abhängig machen. Im Folgenden wird eine Lösung vorgestellt, die für die Absicherung der Authentifizierung keine Änderungen an der Prozessdefinition erfordert Middleware Authentication Beschreibung Die Endpunkte eines BPEL Prozesses werden in der Regel nicht von der BPEL Engine selbst, sondern von einer Middleware bereitgestellt (siehe 3.1). Eingehende Nachrichten werden daher zunächst von der Middleware verarbeitet, bevor sie an einen BPEL Prozess übergeben werden. Ebenso findet bei Antwortnachrichten des Prozesses eine Verarbeitung durch die Middleware statt. Die Middleware kontrolliert somit den Nachrichtenfluss eines Prozesses. Dadurch ist eine Middleware in der Lage, Sicherheitsmecha35

46 Kapitel 3: Sicherheit in BPEL Engines nismen, wie z.b. die Verschlüsselung und Authentifizierung von Nachrichten, zu übernehmen. Um die Sicherheitsanforderungen eines Prozesses zu erfüllen, muss eine Middleware über entsprechende Fähigkeiten verfügen. Dazu gehört neben der Implementierung von Sicherheitsmechanismen ebenso die ausreichende Konfigurierbarkeit von Endpunkten und deren Operationen. Im Folgenden werden die Konfigurationsmöglichkeiten aufgezählt, die eine Middleware für Endpunkte und deren Operationen mindestens zur Verfügung stellen sollte: Konfiguration der zu verwendenden Verschlüsselungsmechanismen und der zu verschlüsselnden Nachrichtenelemente Konfiguration der zu verwendenden Entschlüsselungsmechanismen und der zu entschlüsselnden Nachrichtenelemente Konfiguration der zu verwendenden Signaturmechanismen und der zu signierenden Nachrichtenelemente Konfiguration der Security Tokens, die in einer Nachricht zwingend enthalten sein müssen Konfiguration der Schlüssel (symmetrisch/asymmetrisch), die für die Entschlüsselung, Verschlüsselung und Signatur von Nachrichten verwendet werden Konfiguration eines Authentication Services, der zur Authentifizierung von Nachrichten verwendet wird Falls die Middleware das SOAP-Protokoll einsetzt, bietet sich WSS für die Absicherung der Nachrichten an (siehe ). Mit Hilfe einer Security Policy können die Sicherheitsanforderungen eines Endpunktes bzgl. WSS definiert werden (siehe ). Security Policies können daher verwendet werden, um die von der Middleware bereitgestellten Endpunkte zu konfigurieren. Die in WS-SecurityPolicy definierten Policy Assertions decken dabei die ersten vier der oben aufgezählten Konfigurationen ab. Dies wird anhand der Security Policy aus Listing 3.2 verdeutlicht, welche etwa für den eingehenden Web Service des Beispielprozesses verwendet werden könnte. Die Security Policy definiert, dass alle ausgetauschten Nachrichten durch einen symmetrischen Schlüssel geschützt sein müssen (SymmetricBinding, Zeile 4). Dieser Schlüssel wird vom Initiator des Nachrichtenaustausch erzeugt und sowohl zur Verschlüsselung, als auch zur Signatur der Nachricht verwendet (ProtectionToken, Zeile 6). Zudem ist erforderlich, dass der Initiator den symmetrischen Schlüssel mit einem X-509-v3 Zertifikat verschlüsselt (X509Token, Zeile 8-13). Eine eingehende Nachricht muss darüber hinaus den Benutzernamen und das Passwort des Initiators enthalten (UsernameToken, Zeile 25). Der SOAP-Body von ein- und ausgehenden Nachrichten muss mit dem symmetrischen Schlüssel verschlüsselt und signiert werden (SignedParts, EncryptedParts, Zeile 28-33). Für die Verschlüsselung soll der Algorithmus TripleDes verwendet werden, für die Signatur der Algorithmus Rsa15 (AlgorithmSuite, Zeile 18). 36

47 Kapitel 3: Sicherheit in BPEL Engines [...] <wsp:policy xmlns:wsp="http://www.w3.org/ns/ws-policy" xmlns="...docs.oasis-open.org/ws-sx/ws-securitypolicy/200702"> <SymmetricBinding> <wsp:policy> <ProtectionToken> <wsp:policy> <X509Token IncludeToken=".../IncludeToken/Never"> <wsp:policy> <RequireThumbprintReference /> <WssX509V3Token11 /> </wsp:policy> </X509Token> </wsp:policy> </ProtectionToken> <AlgorithmSuite> <wsp:policy> <TripleDesRsa15 /> </wsp:policy> </AlgorithmSuite> </wsp:policy> </SymmetricBinding> <SupportingTokens> <wsp:policy> <UsernameToken IncludeToken=".../AlwaysToRecipient" /> </wsp:policy> </SupportingTokens> <SignedParts> <Body /> </SignedParts> <EncryptedParts> <Body /> </EncryptedParts> </wsp:policy> [...] Listing 3.2: Security Policy für den eingehenden Endpunkt des Beispielprozesses Die Security Policy definiert damit sowohl für einen Service Requestor, als auch für den Service Provider, wie die Absicherung eines Nachrichtenaustauschs zu erfolgen hat. Sie macht jedoch keine Aussagen darüber, welche konkreten Schlüssel dabei verwendet werden. Beispielsweise fehlt in Listing 3.2 die Angabe, mit welchem Zertifikat der Initiator den generierten, symmetrischen Schlüssel schützen soll und wo er dieses Zertifikat finden kann. Dasselbe gilt auf Seiten des Service Providers, für den ebenfalls nicht definiert ist, mit welchem privaten Schlüssel er den Schutz des symmetrischen Schlüssels aufheben kann. Damit ein Service Provider, wie z.b. die Middleware, die eingehende Kommunikation eines Endpunkts absichern kann, müssen ihm die dazu notwendigen Schlüssel bekannt gemacht werden. Die Konfiguration der bei einem Nachrichtenaustausch zu verwendenden Schlüssel ist auf verschiedene Arten denkbar. Beispielsweise kann dies über separate Konfigurationsdateien erfolgen. Eine andere Möglichkeit ist, die für die Schlüsselzugriffe erforderlichen Informationen ebenfalls innerhalb einer Policy anzugeben. Dazu muss eine zusätzliche Policy Assertion definiert werden. Für den Beispielprozess könnte die Konfiguration der Middleware etwa durch die in Listing 3.3 gezeigte Policy Assertion durchgeführt werden. 37

48 Kapitel 3: Sicherheit in BPEL Engines [...] <wsp:policy xmlns:wsp="http://www.w3.org/ns/ws-policy"> <Configuration xmlns="http://mymiddleware.security-settings"> <Key id="saleskey"> <Filepath>/org/sales/sales.jks</Filepath> <User>salesProcess</User> <Password>salesProcessPassword</Password> </Key> <DecryptionKey idref="#saleskey"/> <Configuration> </wsp:policy> [...] Listing 3.3: Policy Assertion zur Definition von Schlüsselzugriffen Das Element Key enthält alle Angaben, die benötigt werden, um auf den privaten Schlüssel der Einkaufsabteilung zuzugreifen. Der Schlüssel ist in einem Java Keystore (JKS) gespeichert, dessen Dateipfad im Element Filepath angegeben ist. In einem JKS werden in der Regel die Schlüssel mehrerer Benutzer gespeichert, wobei private Schlüssel jeweils über Benutzerpasswörter abgesichert sind. Die Elemente User und Password geben entsprechend den Benutzernamen bzw. das Passwort für den privaten Schlüssel der Einkaufsprozesses an. Da dieser Schlüssel von der Middleware zur Entschlüsselung (des symmetrischen Schlüssels) verwendet werden soll, wird er im Element DecryptionKey referenziert. Für die Verschlüsselung und Signatur der Antwortnachricht sind keine Schlüssel angegeben, da hierzu der symmetrische Schlüssel aus der Eingangsnachricht verwendet werden muss. Aufgrund der sensiblen Daten, die in der Policy enthalten sind, sollte diese unbedingt vor Service Requestors geheim gehalten werden. Eine eingehende Nachricht muss laut der Security Policy in Listing 3.2 einen Benutzernamen und ein Passwort beinhalten. Damit Nachrichten authentifiziert werden, müssen diese Angaben überprüft werden. Diese geschieht in der Regel durch Authentication Services (siehe ). Um eine Authentifizierung durchzuführen, muss die Middleware daher in der Lage sein, Authentication Services aufzurufen. Für jeden Prozess, und, falls nötig, auch für Endpunkte oder Operationen eines Prozesses, sollten unterschiedliche Authentication Services konfiguriert werden können. Ansonsten wäre es z.b. unmöglich, lokale oder temporäre Benutzer für einen Prozess zu definieren. Alternativ kann auch ein zentraler Authentication Service verwendet werden, der durch die Übergabe von Parametern (z.b. einem Prozessbezeichner) eine prozessspezifische Authentifizierung durchführt. In beiden Fällen muss eine Middleware entsprechend konfigurierbar sein. Die Konfiguration könnte hierbei innerhalb der Policy Assertion stattfinden, die bereits zur Definition der Schlüssel verwendet wurde. Listing 3.4 zeigt ein entsprechendes Beispiel. 38

49 Kapitel 3: Sicherheit in BPEL Engines [...] <wsp:policy xmlns:wsp="http://www.w3.org/ns/ws-policy"> [...] <Configuration xmlns="http://mymiddleware.security-settings"> [...] <Authentication> <Address>http://localhost/org/AuthenticationService</Address> <AppliesTo>org.sales.SalesProcess</AppliesTo> </Authentication> [...] <Configuration> </wsp:policy> [...] Listing 3.4: Policy Assertion zur Definition des Authentification Services Innerhalb des Elements Authentication ist die Adresse des Authentication Services des Unternehmens angegeben. Zusätzlich wird im Element AppliesTo der Bezeichner des Einkaufsprozesses als Parameter festgelegt. Dadurch kann der Authentication Service eine prozessspezifische Authentifizierung durchführen. Das Beispiel stellt also eine Kombination der oben genannten Konfigurationsmöglichkeiten dar. Der Authentication Service in Listing 3.4 ist als Web Service implementiert. Wenn dieser Web Service öffentlich zugänglich ist, kann auch eine Authentifizierung nach der in vorgestellten Single Sign-On Methode erfolgen. Die Middleware würde den Authentication Service dann nicht selbst aufrufen, sondern diese Aufgabe den Service Requestors überlassen. Es müsste dann lediglich die Gültigkeit der ausgestellten Authentifizierungsbestätigungen überprüft werden. Bewertung Vorteile Die Sicherheitslogik und die Geschäftslogik eines Prozesses bleiben getrennt. Änderungen an der Sicherheitslogik erfordern keine Änderungen an der Prozessdefinition. Es können beliebige Verschlüsselungsmechanismen und Authentifizierungsverfahren (z.b. Single Sign-On) eingesetzt werden. Die Komplexität der Prozessdefinition nimmt ab, da sie sich nur auf die Geschäftslogik beschränkt. Sicherheitsanforderungen können in Form von Security Policies einmal definiert und anschließend auf verschiedene Endpunkte angewandt werden. Es werden keine unnötigen Prozessinstanzen erzeugt, falls sich ein Benutzer nicht authentifizieren kann. Durch die Absicherung der Nachrichten auf Nachrichtenebene ist eine End-to-End Security gewährleistet (siehe ). Nachteile Benutzerinformationen werden nicht an den Prozess weitergegeben und können daher keiner Prozessinstanz zugewiesen werden. 39

50 Kapitel 3: Sicherheit in BPEL Engines Insgesamt ist diese Lösung deutlich eleganter und flexibler als die des vorherigen Kapitels. Zudem kann der Nachteil dieser Lösung, die fehlende Weitergabe der Benutzerinformationen, beseitigt werden: Die einfachste Lösung hierfür wäre es, die Middleware so zu konfigurieren/erweitern, dass sie die Benutzerinformationen in die Nutzdaten der Nachricht einfügt. Dies würde jedoch wieder zu einer Vermischung von funktionalen und nicht-funktionalen Daten führen. Eine bessere Lösung ist, die Benutzerinformationen separat, z.b. innerhalb eines Header Elementes, zu übergeben. Alternativ kann auch nach dem Pull-Prinzip vorgegangen werden. Die BPEL Engine muss dann so modifiziert werden, dass sie die Benutzerinformationen selbstständig von der Middleware anfordert. 3.4 Speicherung, Struktur und Abfrage von Benutzerinformationen Laut Beschreibung des Beispielprozess dürfen Bestellvorgänge nur von denjenigen Mitarbeiter abgebrochen werden können, die sie gestartet haben. Die Genehmigung einer Bestellung soll je nach Rolle des Mitarbeiters unterschiedlich erfolgen. Zudem sollen, abhängig von den genehmigenden Person, ausgehende Nachrichten unterschiedlich signiert werden. Diese Anforderungen machen es erforderlich, dass zu jedem Bestellvorgang Informationen über die daran beteiligten Benutzer erfasst werden. Da ein Bestellvorgang durch eine Prozessinstanz repräsentiert wird, muss gespeichert werden, welcher Benutzer welche Operation der Prozessinstanz aufgerufen hat. Um solche Benutzerinformationen nach Abstürzen oder Wartungen des Systems wiederherstellen zu können, sollte die Speicherung zudem persistent erfolgen. Die Speicherung der Benutzerinformationen kann nicht von der Middleware durchgeführt werden, da diese keine Kenntnis über die Prozessinstanzen der BPEL Engine hat: Wenn eine eingehende Nachricht durch die Middleware verarbeitet wird, kann diese nicht wissen, für welche Prozessinstanz die Nachricht letztlich bestimmt ist. Die Prozessinstanz wird erst durch den Korrelationsprozess ermittelt, welcher innerhalb der BPEL Engine stattfindet (siehe 3.1). Daher muss auch die Speicherung der Benutzerinformationen durch die BPEL Engine erfolgen. Im Folgenden werden hierzu zwei Möglichkeiten vorgestellt Speicherung innerhalb von Variablen Beschreibung In wird die Absicherung der eingehenden Kommunikation durch eine Authentifizierung über BPEL Code erreicht. Ein Benutzer muss dazu seinen Namen innerhalb der Nutzdaten einer Nachricht angeben. Die Eingangsvariablen einer Prozessinstanz enthalten daher bereits Benutzerinformationen. Da eine BPEL Engine für die persistente Speicherung der Variablen einer Prozessinstanz sorgt, bleiben auch die darin enthaltenen Benutzerinformationen erhalten. 40

51 Kapitel 3: Sicherheit in BPEL Engines 1 <process xmlns=".../process/executable" 2 xmlns:sec="http://my-bpel-engine/security"> 3 [...] 4 <variables> 5 <variable name="orderrequest" messagetype="tns:order"/> 6 <variable name="starter" type="sec:usercontext"/> 7 [...] 8 </variables> 9 <sequence> 10 <receive name="startorder" createinstance="yes" 11 partnerlink="salespartnerlink" operation="startorder" 12 inputvariable="orderrequest" sec:usercontext="starter"/> 13 [...] 14 </sequence> 15 </process> Listing 3.5: Übergabe von Benutzerinformationen über das Attribut usercontext Um diese Lösung auch bei einer Authentifizierung durch die Middleware zu ermöglichen, muss eine Weitergabe der Benutzerinformationen an die BPEL Engine erfolgen. Die Benutzerinformationen können dazu beispielsweise innerhalb eines Header-Elementes platziert werden. Die BPEL Engine ist dann in der Lage, aus den übergebenen Benutzerinformationen Variablen zu erzeugen. Um dabei eine implizite Deklaration von Variablen zu vermeiden, könnte etwa das in Listing 3.5 gezeigte Konzept verwendet werden. Zusätzlich zu den normalen Variablen des Prozesses werden Variablen deklariert, die Benutzerinformationen aufnehmen können (starter, Zeile 6). Diese Variablen können in jeder IMA über das Erweiterungsattribut sec:usercontext referenziert werden (Zeile 12). Das Erweiterungsattribut gibt, analog zum Attribut inputvariable, diejenige Variable an, in der die Benutzerinformationen des Aufrufs gespeichert werden sollen. Die BPEL Engine wird so erweitert, dass sie die entsprechende Zuweisung durchführt, falls das Attribut in einer IMA angegeben ist. Bewertung Vorteile Auf Benutzerinformationen kann wie auf eine normale Variable zugegriffen werden. Die Informationen können z.b. kopiert, verändert und miteinander verglichen werden. Die Speicherung der Benutzerinformationen erfolgt über vorhandene Mechanismen der BPEL Engine. Im Bereich der Datenspeicherung sind keine Änderungen an der BPEL Engine notwendig. Durch Weitergabe der Benutzerinformationen können ausgehende Aufrufe im Namen eines bestimmten Benutzers ausgeführt werden. Nachteile Um alle Benutzerinformationen einer Prozessinstanz zu speichern, muss für jede Instanz einer IMA eine zusätzliche Variable deklariert werden. Bei einer Veränderung der Variablen können Benutzerinformationen der Prozessinstanz verloren gehen. 41

52 Kapitel 3: Sicherheit in BPEL Engines Um die Benutzerinformationen einer Prozessinstanz vollständig zu erfassen, ohne für jeden Aufruf eine Variable deklarieren zu müssen, kann die im nächsten Kapitel beschriebene Lösung verwendet werden Speicherung außerhalb von Variablen Beschreibung Neben den Werten von Variablen, Partnerlinks und Korrelationen speichert eine BPEL Engine noch eine Vielzahl an weiteren Daten zu einer Prozessinstanz und den darin erzeugten Scopes und Aktivitäten. Dazu gehören u.a. Eindeutige Bezeichner Aktuelle Status (aktiv, abgeschlossen, abgebrochen, etc.) Erzeugungs- bzw. Ausführungszeitpunkte Es bietet sich an, diese Daten um Informationen über die Benutzer der Prozessinstanz zu erweitern. Beispielsweise können zu jeder ausgeführten IMA die Benutzerinformationen des entsprechenden Aufrufs gespeichert werden. Für den Zugriff auf die Benutzerinformationen könnte etwa das in [LLM+08] vorgestellte Schema verwendet werden. Darin werden Prozessinstanzen und die in Prozessinstanzen enthaltenen Aktivitäten auf Ressourcen abgebildet und können über XPath-Ausdrücke adressiert werden. Der XPath-Ausdruck /{http://org/sales}salesprocess/instances/134/process/sequence/receive[1] etwa verweist auf die erste receive-aktivität innerhalb der Prozessinstanz 134 des Einkaufsprozesses. Die gespeicherten Benutzerinformationen wären eine Eigenschaft dieser Aktivität/Ressource. Um auf diese Weise auf Eigenschaften von Aktivitäten zugreifen zu können, muss die BPEL Engine zunächst das vorgestellte Zugriffsschema implementieren. Zudem muss eine Schnittstelle bereitgestellt werden, über die die Eigenschaften der Ressourcen abgefragt werden können. Dabei kann auf Standards, wie z.b. WS-ResourceProperties [WSRP06] zurückgegriffen werden, in denen die Operationen einer solchen Schnittstelle definiert sind. Um den Zugriff auf Benutzerinformationen innerhalb der Prozessdefinition zu ermöglichen, kann die BPEL Engine um eine zusätzliche XPath-Funktion erweitert werden. Listing 3.6 liefert hierfür ein Beispiel. 42

53 Kapitel 3: Sicherheit in BPEL Engines 1 <process xmlns=".../process/executable" 2 xmlns:sec="http://my-bpel-engine/security"> 3 [...] 4 <variables> 5 <variable name="starter" type="sec:usercontext"/> 6 [...] 7 </variables> 8 <sequence> 9 <receive name="startorder" createinstance="yes" 10 partnerlink="salespartnerlink" operation="startorder" 11 inputvariable="orderrequest"/> 12 <assign> 13 <copy> 14 <from>sec:getusercontext("process/sequence/receive[1]")</from> 15 <to>$starter</to> 16 </copy> 17 </assign> 18 [...] 19 </sequence> 20 </process> Listing 3.6: Zugriff auf den Benutzerkontext durch eine Ressourcenabfrage Die Funktion getusercontext ruft die Benutzerinformationen für beliebige Aktivitäten der aktuellen Prozessinstanz ab (Zeile 14). Die Aktivität wird dabei über einen XPathAusdruck spezifiziert. Der XPath-Ausdruck gibt die Position der Aktivität im XML-Dokument an und wird der Funktion als Parameter übergeben. Innerhalb der Funktion wird der XPath-Ausdruck um den Namen des Prozesses und die Nummer der Prozessinstanz erweitert. Dadurch entsteht ein Ausdruck, der dem oben beschriebenen Zugriffsschema entspricht. Über die Schnittstelle der BPEL Engine werden anschließend die entsprechenden Benutzerinformationen abgerufen und als Ergebnis der Funktion zurückgegeben. Das Ergebnis wird anschließend einer Variablen zugewiesen, welche die entsprechenden Benutzerinformationen aufnehmen kann (to, Zeile 15). Bewertung Vorteile Benutzerinformationen werden gespeichert, ohne dass Variablen deklariert werden müssen. Benutzerinformationen können in Variablen kopiert und anschließend genauso flexibel verwendet werden. Auf Benutzerinformationen kann (evtl. auch von außen) über ein einheitliches Zugriffsschema zugegriffen werden. Nachteile Die BPEL Engine muss das in [LLM+08] definierte Zugriffsschema unterstützen und Schnittstellen für den Zugriff auf Ressourcen bereitstellen. Zur Speicherung der Benutzerinformationen müssen Änderungen am Datenbankschema der BPEL Engine vorgenommen werden. Die BPEL Engine muss zusätzliche XPath-Funktionen implementieren. 43

54 Kapitel 3: Sicherheit in BPEL Engines Insgesamt empfiehlt es sich, beide vorgestellten Umsetzungsalternativen zu implementieren, da diese sich gut ergänzen: Die erste Lösung ermöglicht eine einfache und flexible Verwendung von Benutzerinformationen innerhalb der Prozessdefinition. Die zweite Lösung stellt hingegen die persistente und statische Speicherung aller Benutzerinformationen einer Prozessinstanz sicher. Nachdem nun zwei Lösungen zur Speicherung der Benutzerinformationen vorgestellt wurden, stellt sich die Frage, welche Angaben in diesen Daten überhaupt enthalten sein sollten. Diese Frage wird im folgenden Kapitel erörtert Struktur und Abfrage von Benutzerinformationen Zur Absicherung und Ausführung eines Bestellvorgangs muss auf Attribute der beteiligten Personen zugegriffen werden. Beispielsweise ist an diversen Stellen die Überprüfung von Rollenzugehörigkeiten erforderlich. Aus diesem Grund müssen die von einer Prozessinstanz gespeicherten Benutzerinformationen einen Zugriff auf die Rollen der Benutzer erlauben. Eine Möglichkeit hierfür ist, dass der Authentication Service bei einer erfolgreichen Authentifizierung alle Rollen des jeweiligen Benutzer in Form von Attributen zurück liefert. Diese Attribute können von der BPEL Engine als Benutzerinformationen gespeichert und über XPath-Ausdrücke abgefragt werden. Es ist jedoch fraglich, ob ein solches Vorgehen in allen Prozessen sinnvoll ist. Betrachtet man etwa den Beispielprozess, so würde dies im folgenden Fall zu einer unberechtigten Bestellung führen: Ein Abteilungsleiter gibt eine Bestellung auf. Während der Angebotsphase wird ihm gekündigt und infolgedessen die Rolle des Abteilungsleiters entzogen. Da die Benutzerinformationen der Prozessinstanz jedoch vom Zeitpunkt der Bestellabgabe stammen, wird nach Abgabe der Angebote die Bestellung dennoch automatisch genehmigt. Aus diesem Grund ist es sinnvoll, bestimmte Attribute eines Benutzers erst zu den Zeitpunkten abzurufen, an denen sie verwendet werden. Um dies zu ermöglichen, wird die im Folgenden beschriebene Vorgehensweise vorgeschlagen. Der Authentication Service gibt die Benutzerinformationen in einer XML Struktur, ähnlich der aus Listing 3.7, zurück. Die Struktur enthält dabei mindestens die folgenden Informationen über den Benutzer: Den eindeutigen Bezeichner des Bereichs, in dem der Benutzer definiert ist (Attribut realm). Den eindeutigen Bezeichner des Benutzers in dem angegebenen Realm (Attribut id). Zudem können optional beliebig viele Attribute in der Struktur angegeben sein. Die Struktur der Attribute kann dabei beispielsweise von XACML übernommen werden (siehe ). 44

55 Kapitel 3: Sicherheit in BPEL Engines 1 <user xmlns="http://my-bpel-engine/security" 2 realm="org.identities" id="hr72si"> 3 Static Attributes (e.g. given name, birthday etc.) 4 </user> Listing 3.7: Benutzerinformationen zu einem Prozessaufruf Wenn innerhalb eines Prozesses das Attribut eines Benutzers benötigt wird, kann die BPEL Engine zunächst in den zurückgegebenen Benutzerinformationen danach suchen. Falls das Attribut dort nicht gefunden wird, ist es in einem zweiten Schritt möglich, das Attribut mit Hilfe der oben genannten, eindeutigen Bezeichner abzufragen. Dazu muss einer BPEL Engine zu jedem Realm der jeweils zuständige Identity Service bekannt gemacht werden. Dies kann beispielsweise über die globalen Einstellungen der BPEL Engine oder prozessspezifisch im Deployment Descriptor erfolgen. Listing 3.8 liefert ein Beispiel, wie der Identity Service in beiden Fällen definiert werden könnte. 1 <identity-service xmlns="http://my-bpel-engine/security" 2 realm="org.identities" type="webservice"> 3 <address>http://localhost/orgs/identityservice</address> 4 </identity-service> Listing 3.8: Definition eines Identity Services Um den Zugriff auf Benutzerattribute innerhalb der Prozessdefinition zu ermöglichen, bietet sich wiederum die Erweiterung der BPEL Engine um zusätzliche XPath-Funktionen an. Folgende Funktionen werden dazu vorgeschlagen: getattributes(usercontext userxml) Gibt alle Attribute eines Benutzers zurück. getattribute(usercontext userxml, String attributename) Gibt ein bestimmtes Attribut eines bestimmten Benutzers zurück. getattributevalue(usercontext userxml, String attributename) Gibt den Wert eines bestimmten Attributes eines bestimmten Benutzers zurück. Listing 3.9 zeigt, wie eine solche Funktion etwa zur Rollenüberprüfung innerhalb des Beispielprozesses verwendet werden könnte. 1 <process xmlns=".../process/executable" 2 xmlns:sec="http://my-bpel-engine/security"> 3 <variables> 4 <variable name="starter" type="sec:usercontext"/> [...] 5 </variables> 6 <sequence> 7 [...] 8 <if> 9 <condition> 10 exists(sec:getattributevalue($starter, 11 </condition> 12 [...] 13 </if> 14 </sequence> 15 </process> Listing 3.9: Abfrage von Benutzerattributen 45

56 Kapitel 3: Sicherheit in BPEL Engines Der Code, den die BPEL Engine bei Aufrufen dieser XPath-Funktionen intern ausführt, kann beliebig komplex sein. Beispielsweise wäre es möglich, dass der Identity Service, von dem die Attribute abgerufen werden, über eine Web Service Schnittstelle verfügt und daher ein Web Service Aufruf erfolgen muss. Zudem muss zur Abfrage der Attribute unter Umständen eine Attribute Query (z.b. in SAML) formuliert werden. Um diese Komplexität zu kapseln, kann eine Abstraktionsschicht zwischen der BPEL Engine und den Identity Services eingefügt werden (siehe Abbildung 3.5). Dazu wird eine Schnittstelle definiert, die den Zugriff auf die Attribute eines Benutzers vereinheitlicht. Implementierungen dieser Schnittstelle können durch die Formulierung entsprechender Anfragen auf verschiedenartige Identity Services zugreifen und im Anschluss für eine Konvertierung der Rückgaben sorgen. Zudem ist es möglich, dass eine Implementierung der Schnittstelle selbst als Identity Service fungiert, etwa indem sie Benutzerattribute aus lokalen Dateien ausliest und diese zurück liefert. Abbildung 3.5: Abstraktionsschicht zwischen BPEL Engine und Identity Services 3.5 Zugriffskontrolle Laut Beschreibung des Beispielprozesses dürfen nur interne Mitarbeiter Beschaffungsanträge aufgeben. In der Mitarbeiterdatenbank des Unternehmens sind jedoch die Daten aller Mitarbeiter angegeben. Wenn man die eingehende Kommunikation wie in Kapitel 3.3 beschrieben absichert, könnten daher immer noch externe Mitarbeiter Bestellungen tätigen. Außerdem wäre es nach wie vor für alle Mitarbeiter des Unternehmens möglich, Bestellungen zu genehmigen, abzulehnen oder die Anträge anderer Mitarbeiter zurückzuziehen. Um dies zu verhindern muss zusätzlich zur Authentifizierung eine Autorisierung der eingehenden Nachrichten stattfinden. Im folgenden werden drei Alternativen zur Realisierung von Zugriffskontrolle für BPEL Prozesse diskutiert. 46

57 Kapitel 3: Sicherheit in BPEL Engines Instance Authorization Beschreibung Analog zu der in Kapitel beschriebenen Authentifizierungsvariante kann auch eine Autorisierung innerhalb des Prozesses durchgeführt werden. Dies kann imperativ und/oder deklarativ erfolgen. Bei der imperativen Variante wird eine Zugriffsberechtigungen durch die Ausführung von (BPEL) Code überprüft. So können im Beispielprozess etwa nach jeder receive und onmessage-aktivität Codeabschnitte eingefügt werden, welche die jeweils erforderliche Rollenüberprüfung durchführen (vgl. Listing 3.9). Um solche herkömmlichen Autorisierungsmechanismen zu erleichtern, wird zusätzlich eine deklarative Autorisierung vorgeschlagen. Diese kann als Äquivalent zu den Security Annotations der JEE27 [SUN05] und der deklarativen Code Access Security des.net Frameworks28 [MIC09] angesehen werden. Statt der Sicherheitsanforderungen von Java bzw..net Code werden in diesem Fall jedoch die Sicherheitsanforderungen von BPEL Code deklariert. Die Deklaration erfolgt hierbei über BPEL Erweiterungsattribute. Beispielsweise kann, analog zur JEE Annotation rolesallowed, ein BPEL Erweiterungsattribut rolesallowed eingeführt werden, mit dem autorisierte Rollen einer IMA angegeben werden können. Listing 3.10 zeigt die Verwendung dieses Attributs (Zeile 7). 1 <process xmlns=".../process/executable" 2 xmlns:sec="http://my-bpel-engine/security"> 3 [...] 4 <sequence> 5 <receive name="startorder" createinstance="yes" 6 partnerlink="salespartnerlink" operation="startorder" 7 inputvariable="orderrequest" sec:rolesallowed="employee, Admin"/> 8 [...] 9 </sequence> 10 </process> Listing 3.10: Deklarative Autorisierung innerhalb des Prozesses Die deklarative Autorisierung birgt zusätzlich den Vorteil, dass die BPEL Engine vor dem Aufruf der entsprechenden Aktivität eine Autorisierung durchführen kann. Im Gegensatz zur imperativen Autorisierung ist es daher möglich, Prozessinstanzen nur dann auszuführen, wenn Benutzer auch über die notwendigen Rollen/Berechtigungen verfügen. Bewertung Vorteile Größtmögliche Flexibilität bei der Autorisierung durch Ausführung von Code (nur imperative Autorisierung) Java Platform, Enterprise Edition, ( ) ( ) 47

58 Kapitel 3: Sicherheit in BPEL Engines Auf fehlgeschlagene Autorisierungen kann im Prozess reagiert werden (nur imperative Autorisierung). Prozessinstanzen werden nur dann ausgeführt, wenn ein Aufrufer über die benötigten Berechtigungen verfügt (nur deklarative Autorisierung). Nachteile In der Prozessdefinition wird (funktionale) Geschäftslogik mit (nicht-funktionaler) Sicherheitslogik vermischt. Bei Änderungen der Sicherheitslogik muss die Prozessdefinition angepasst werden. In der Prozessdefinition sind sicherheitsrelevante Daten, wie z.b. Rollen- oder Benutzernamen, angegeben. Bei Änderungen dieser Daten muss die Prozessdefinition angepasst werden. Es werden auch Prozessinstanzen erzeugt, wenn ein Benutzer nicht autorisiert ist (nur imperative Autorisierung). Unter Umständen müssen viele verschiedene Erweiterungsattribute definiert werden (nur deklarative Autorisierung) Middleware Authorization Beschreibung Analog zur Authentifizierung kann auch die Autorisierung von Nachrichten innerhalb der Middleware durchgeführt werden. Die Middleware muss dazu für Endpunkte eine weitere Konfigurationsmöglichkeit anbieten (vgl ): Konfiguration eines Authorization Services, der zur Autorisierung von Nachrichten verwendet wird Die Konfiguration kann dabei ähnlich wie die des Authentication Services in Listing 3.4 erfolgen. Falls für einen Endpunkt ein Authorization Service definiert ist, muss die Middleware bei Aufrufen des Endpunktes als Policy Enforcement Point agieren (siehe ): Sobald eine Nachricht eintrifft und der Benutzer authentifiziert wurde, muss eine entsprechende Autorisierungsanfrage (Decision Request) formuliert und an den Authorization Service den Policy Decision Point übergeben werden. Für die Formulierung des Decision Requests bietet sich XACML an (siehe ). Informationen über das Subjekt können hierbei dem Security Token entnommen werden, welches durch den Authentication Service ausgestellt wurde. Die Ressource, auf die zugegriffen wird, lässt sich unter anderem durch die folgenden Attribute beschreiben: Den Namen des aufgerufenen Endpunkts 48

59 Kapitel 3: Sicherheit in BPEL Engines Den Namen der aufgerufenen Operation Die Endpunktadresse Enthält der Decision Request die entsprechenden Angaben, so können die Policies des Authorization Services beliebig komplexe Regeln auf dem Subjekt und der Ressource auswerten. Listing 3.11 zeigt etwa eine für den Beispielprozess geeignete XACML Policy, die nur Mitarbeitern die Aufgabe von Bestellungen erlaubt. Hierbei wird zunächst ermittelt, ob es sich bei der angegebenen Ressource um die Startoperation des Prozesses handelt (Zeile 7-14). Ist dies der Fall, findet die Regelauswertung statt, bei der überprüft wird, ob das angegebene Subjekt die Rolle Employee besitzt (Zeile 20-23). 1 <Policy xmlns="urn:oasis:names:tc:xacml:2.0:context" 2 PolicyId="sales:SalesProcessStartOrderPolicy" 3 RuleCombiningAlgId="...rule-combining-algorithm:deny-overrides"> 4 <Target> 5 <Subjects><AnySubject/></Subjects> 6 <Resources> 7 <ResourceMatch MatchId="...function:string-equal"> 8 <AttributeValue>{org.sales}SalesProcess</AttributeValue> 9 <ResourceAttributeDesignator AttributeId="sales:endpoint"/> 10 </ResourceMatch> 11 <ResourceMatch MatchId="...function:string-equal"> 12 <AttributeValue>startOrder</AttributeValue> 13 <ResourceAttributeDesignator AttributeId="sales:operation"/> 14 </ResourceMatch> 15 </Resources> 16 <Actions><AnyAction/></Actions> 17 </Target> 18 <Rule RuleId="sales:IsEmployeeRule" Effect="Permit"> 19 <Target /> 20 <Condition FunctionId="...function:string-is-in> 21 <AttributeValue>Employee</AttributeValue> 22 <SubjectAttributeDesignator AttributeId="sales:role"/> 23 </Condition> 24 </Rule> 25 </Policy> Listing 3.11: XACML Policy für die Operation startorder des Beispielprozesses Bewertung Vorteile Die Sicherheitslogik und die Geschäftslogik eines Prozesses bleiben getrennt. Änderungen an der Sicherheitslogik erfordern keine Änderungen an der Prozessdefinition. Policies können einmal definiert und anschließend auf verschiedene Prozesse/Endpunkte angewandt werden. Prozessinstanzen werden nur dann ausgeführt, wenn ein Aufrufer über die benötigten Berechtigungen verfügt. Nachteile Bei der Autorisierung kann nicht auf Daten der Prozessinstanz, für die die Nachricht bestimmt ist, zurückgegriffen werden. 49

60 Kapitel 3: Sicherheit in BPEL Engines Dadurch, dass kein Zugriff auf die Eigenschaften der Prozessinstanz möglich ist, können beispielsweise keine Richtlinien formuliert werden, welche die Benutzer der Prozessinstanz mit dem Sender der Nachricht vergleichen. Im Beispielprozess ist dies jedoch notwendig. So darf eine Bestellung beispielsweise nur von derjenigen Person zurückgezogen werden, welche die Bestellung aufgegeben hat. Im nächsten Kapitel wird eine weitere Umsetzungsmöglichkeit beschrieben, mit der sich die Durchsetzung solcher Richtlinien realisieren lässt, ohne die Nachteile der Lösung aus in Kauf nehmen zu müssen Process Authorization Beschreibung Bestimmte Richtlinien können den Zugriff auf Daten einer Prozessinstanz erforderlich machen. Da erst die BPEL Engine ermittelt, für welche Prozessinstanz eine Nachricht bestimmt ist, können solche Richtlinien nicht auf Middleware-Ebene ausgewertet werden. Stattdessen muss eine Auswertung auf Ebene der BPEL Engine stattfinden. Hierzu wird das im Folgenden beschriebene Konzept vorgeschlagen. Viele BPEL Engines, wie z.b. Apache ODE, verfügen über ein Event-Modell, durch das Ereignisse eines Prozesses und dessen Instanzen überwacht werden können. Zwei dieser Event-Modelle werden in [KKS+06] und [Ste08] vorgestellt. Verfügt eine BPEL Engine über ein solches Event-Modell, so sind Komponenten in der Lage, sich bei der Engine auf Ereignisse zu registrieren und diese abzuhören. Zu solchen Ereignissen gehören unter anderem Zustandsübergange von Aktivitäten. Beispielsweise wird vor der Ausführung einer Aktivität ein entsprechendes Ereignis ausgelöst. Eine Komponente, die sich auf solche Ereignis registriert hat, ist in der Lage, die Ausführung der Aktivitäten zu verhindern. Dieser Mechanismus kann genutzt werden, um eine Zugriffskontrolle auf Ebene der Aktivitäten einer Prozessinstanz zu realisieren: Es wird eine (Erweiterungs-)Komponente für die BPEL Engine entwickelt, die die Ausführung von Aktivitäten überwacht. Sobald eine Aktivität ausgeführt werden soll, formuliert die Komponente aus den Daten des Ereignisses einen entsprechenden Decision Request (z.b. in XACML) und gibt diesen an einen zuvor konfigurierten Authorization Service weiter. Der Authorization Service führt eine Autorisierung durch und gibt das Ergebnis an die Komponente zurück. Wurde keine Autorisierung erteilt, verhindert die Komponente die Ausführung der Aktivität. Die Komponente stellt somit einen Reference Monitor dar (siehe ). Falls erforderlich, kann eine Autorisierung nicht nur für IMAs, sondern für alle Arten von BPEL Aktivitäten durchgeführt werden. Wenn ein Zugriff während der Ausführung einer Prozessinstanz verweigert wird, muss die Prozessinstanz in einen definierten Fehlerzustand übergehen. Vorgeschlagen wird, dass in diesem Fall von der BPEL Engine der Fehler (fault) authorizationdenied aus50

61 Kapitel 3: Sicherheit in BPEL Engines gelöst wird. Auf diese Weise ist es möglich, innerhalb der Prozessdefinition auf die fehlgeschlagene Autorisierung zu reagieren (mittels eines entsprechenden Fault Handlers). Komplexe Richtlinien lassen sich oft nur sehr schwer generisch definieren. Als Beispiel kann hierfür der Abbruch von Bestellungen im Beispielprozess genommen werden: Die Aktivität cancelorder einer Prozessinstanz darf nur von demjenigen aufgerufen werden, der die entsprechende Prozessinstanz durch Aufruf der Aktivität startorder gestartet hat. Ein Decision Request für die Aktivität cancelorder müsste daher die Benutzerinformationen beider Aktivitäten enthalten. Da Decision Requests von dem Reference Monitor erzeugt werden, würde dies wiederum eine relativ komplexe Konfigurierbarkeit des Reference Monitors erforderlich machen. Um die Konfigurierbarkeit des Reference Monitors so einfach wie möglich zu halten und gleichzeitig beliebig komplexe Richtlinien zu erlauben, könnten beispielsweise die folgenden Erweiterungen vorgenommen werden: 1. Zwischen Reference Monitor und Authorization Service werden Adapter eingefügt, die für die Formulierung des Decision Requests und den Aufruf des Authorization Services zuständig ist. Den Adaptern wird dabei Zugriff auf den Kontext der Ressource (z.b. die Prozessinstanz) gegeben. 2. Der Reference Monitor wird so erweitert, dass mehrere Adapter konfiguriert werden können. Der Reference Monitor ruft bei einem Ressourcenzugriff alle Adapter auf und aggregiert deren Ergebnisse. 3. Es werden Adapter implementiert, die verschiedene Authentication Services aufrufen. Alternativ kann ein Adapter auch selbst die Evaluation von Berechtigungen durchführen. Auf diese Weise ist es möglich Adapter zu entwickeln, die durch die Ausführung von Code beliebig komplexe Richtlinien auswerten können. Gleichzeitig ist jedoch auch eine Zugriffskontrolle durch den Aufruf von Authorization Services möglich. Das beschriebene Konzept ähnelt dem des Java Frameworks Spring Security29, in dem über Implementierungen der Schnittstellen AccessDecisionManager und AccessDecisionVoter eine ähnliche Funktionalität erreicht wird. Bewertung Vorteile Die Sicherheitslogik und die Geschäftslogik eines Prozesses bleiben getrennt. Änderungen an der Sicherheitslogik erfordern keine Änderungen an der Prozessdefinition. Autorisierungen können an beliebigen Stellen der Prozessausführung erfolgen. Zugriff auf Prozessinstanzdaten. Größtmögliche Flexibilität bei der Autorisierung. 29 ( ) 51

62 Kapitel 3: Sicherheit in BPEL Engines Nachteile Relativ hoher Implementierungsaufwand Evtl. hoher Wartungsaufwand der Adapter Die vorgestellte Lösung ermöglicht eine sehr feingranulare Zugriffskontrolle auf Ebene der Aktivitäten eines BPEL Prozesses. Im Gegensatz zu der Lösung aus sind hierbei keine Eingriffe in die Prozessdefinition nötig. Dem gegenüber steht jedoch ein erhöhter Implementierungs- und Wartungsaufwand. Insgesamt wird eine Kombination der drei vorgestellten Lösungen vorgeschlagen: Die Basisabsicherung eines Prozesses erfolgt auf Middleware-Ebene (siehe 3.5.2). Für Richtlinien, die Prozessinstanzdaten mit einbeziehen, wird zusätzlich die in diesem Kapitel vorgestellte Autorisierung ermöglicht. Um einem Prozessmodellierer Möglichkeiten zur Autorisierung von Benutzern zu geben, kann zusätzlich die in beschriebene deklarative Autorisierung implementiert werden. 3.6 Zuweisung von Benutzerinformationen Im Beispielprozess soll die Aufgabe einer Bestellung im Namen der jeweils verantwortlichen Person ausgeführt werden. Daher muss die invoke Aktivität, in der eine Bestellung getätigt wird, mit den entsprechenden Benutzerinformationen assoziiert werden. Zudem ist es denkbar, dass in anderen Prozessen auch weitere Aktivitätstypen Benutzern zugewiesen werden müssen. Beispielsweise könnte eine Extension Activity, die einen Datenbankzugriff durchführt, ebenfalls auf Benutzerinformationen angewiesen sein, die von den Aufrufern der jeweiligen Prozessinstanz abhängig sind. Nachfolgend werden zwei verschiedene Umsetzungsalternativen für die Zuweisung von Benutzerinformationen zu BPEL Aktivitäten diskutiert Zuweisung innerhalb der Prozessdefinition Beschreibung Falls Benutzerinformationen einer Prozessinstanz in Variablen gespeichert werden, kann die Zuweisung der Benutzerinformationen wiederum über ein Erweiterungsattribut realisiert werden. In Anlehnung an die JEE Security Annotations ([SUN05]) wird hierbei runas als Attributname vorgeschlagen. Die Verwendung des Attributes erfolgt wie in Listing 3.12: Als Wert des Attributes wird der Name einer Variablen mit Benutzerinformationen angegeben (Zeile 11). Die Benutzerinformationen werden bei Ausführung der Aktivität von der BPEL Engine als Kontextinformationen bereitgestellt. Dies kann beispielsweise dadurch realisiert werden, dass der Code der Aktivität unter dem, durch die Benutzerinformationen definierten Benutzer ausgeführt wird. Java stellt dazu beispielsweise die statische Funktion Subject.doAs bereit [JAAS]. 52

63 Kapitel 3: Sicherheit in BPEL Engines 1 <process xmlns=".../process/executable" 2 xmlns:sec="http://my-bpel-engine/security"> 3 <variables> 4 <variable name="starter" type="sec:usercontext"/> 5 [...] 6 </variables> 7 <sequence> 8 [...] 9 <invoke name="requestorder" 10 partnerlink="supplierpartnerlink" operation="requestorder" 11 inputvariable="orderrequest" sec:runas="starter"/> 12 </sequence> 13 </process> Listing 3.12: Zuweisung von Benutzerinformationen über das Attribut runas Um einem ganzen Block einem bestimmten Benutzer zuweisen zu können, bietet es sich an, das Attribut auch bei scope Aktivitäten zu erlauben. Werden innerhalb eines Blocks weitere Aktivitäten oder Blöcke erzeugt, sollte die BPEL Engine diesen implizit die Benutzerinformationen des übergeordneten Blocks zuweisen. Ausgenommen davon sind Aktivitäten und Blöcke, denen explizit (über das runas Attribut) Benutzerinformationen zugewiesen sind. Damit eine Prozessinstanz ebenfalls einem Benutzer zugewiesen wird, kann die BPEL Engine dem process Scope automatisch die Benutzerinformationen des ersten Aufrufers, und damit des Erzeugers der Prozessinstanz, zuweisen. Um dies zu unterbinden oder explizit anzugeben, kann zusätzlich das Erweiterungsattribut runasstarter für das process Element definiert werden. Ist der Wert des Attribut no, werden der Prozessinstanz keine Benutzerinformationen zugewiesen. Existiert das Attribut nicht oder ist der Wert yes, werden der Prozessinstanz die Benutzerinformationen des Aufrufers zugewiesen. Alle im process Scope enthaltenen Aktivitäten erben wiederum diese Benutzerinformationen. Für die persistente Speicherung der Zuweisungen von Benutzern zu Aktivitäten/Scopes bietet sich die Lösung aus an. Bewertung Vorteile Benutzerinformationen können im Prozess verändert und anschließend zugewiesen werden. Nachteile Geschäftslogik und Sicherheitslogik werden in der Prozessdefinition vermischt. Um wiederum die Sicherheitslogik von der Geschäftslogik zu trennen, ist eine Zuweisung von Benutzerinformationen auch außerhalb der Prozessdefinition möglich Zuweisung außerhalb der Prozessdefinition Beschreibung Falls der Zugriff auf die Benutzerinformationen einer BPEL Engine über das in vorgestellte Schema möglich ist, kann eine Zuweisung von Benutzerinformationen zu Aktivitäten auch außerhalb der Prozessdefinition festgelegt werden. Listing 3.13 zeigt, 53

64 Kapitel 3: Sicherheit in BPEL Engines 1 <deploy xmlns="http://my-bpel-engine/deployment"> 2 <process name="salesprocess"> 3 [...] 4 <usermapping targetactivity="process/sequence/invoke[2]" 5 sourceactivity="process/sequence/receive[1]" /> 6 </process> 7 </deploy> Listing 3.13: Zuweisung von Benutzerinformationen im Deployment Descriptor wie eine solche Zuweisung im Deployment Descriptor eines Prozesses definiert sein könnte. In dem Listing werden der zweiten invoke Aktivität des Prozesses die Benutzerinformationen der ersten receive Aktivität zugewiesen. Damit diese Benutzerzuweisung (Usermapping) bei der Ausführung des Prozesses durchgeführt wird, ist eine Erweiterung der BPEL Engine erforderlich: Bei der Erzeugung einer Aktivität muss die BPEL Engine zunächst ermitteln, ob diese das Ziel einer Benutzerzuweisung ist. Ist dies der Fall, muss sie die Benutzerinformationen der als Quelle angegebenen Aktivität abfragen und der erzeugten Aktivität zuweisen. Erst danach darf die erzeugte Aktivität ausgeführt werden. Gegebenenfalls ist es erforderlich, einer Aktivität statische Benutzerinformationen zuzuweisen, beispielsweise wenn ein Web Service Aufruf immer unter demselben Benutzer ausgeführt werden soll. Um dies zu ermöglichen, sollte eine Benutzerzuweisung alternativ auch wie in Listing 3.14 angegeben werden können. 1 <usermapping targetactivity="process/sequence/invoke[2]"> 2 <user xmlns="http://my-bpel-engine/security"> 3 id="hr72si" realm="org.identities"> 4 Additional Attributes (e.g. given name, etc.) 5 </user> 6 </usermapping> Listing 3.14: Zuweisung statischer Benutzerinformationen im Deployment Descriptor Bewertung Vorteile Geschäftslogik und Sicherheitslogik bleiben getrennt. Nachteile Es ist eine Erweiterung des Deployment Descriptors notwendig. Benutzerinformationen können vor einer Zuweisung nicht verändert werden. Die vorgestellte Lösungen eignet sich, solange die Zuweisung von Benutzerinformationen zu Aktivitäten unabhängig von der Geschäftslogik eines Prozesses ist. Dies ist jedoch nicht immer der Fall: So muss die Bestellung im Beispielprozess etwa, abhängig vom Prozessverlauf, entweder im Namen des Bestellers (falls dieser ein Abteilungsleiter ist) oder des Genehmigers ausgeführt werden. Aus diesem Grund sollte eine BPEL Engine ebenfalls die in beschriebene Zuweisung von Benutzerinformationen unterstützen. Es wird vorgeschlagen, den Deployment Descriptor von Prozessen so zu erweitern, dass die zu verwendende Zuweisungsmethode konfiguriert werden kann. 54

65 Kapitel 3: Sicherheit in BPEL Engines 3.7 Absicherung der ausgehenden Kommunikation In dem Beispielprozess müssen ausgehende Nachrichten mit den öffentlichen Schlüsseln der Lieferanten verschlüsselt werden. Zudem muss bei der Abgabe einer Bestellung die entsprechende Nachricht mit dem privaten Schlüssel des verantwortlichen Einkäufers oder Abteilungsleiters signiert werden. Anhand der Signatur ist der Lieferant in der Lage, eine Authentifizierung durchzuführen. Ähnlich wie in 3.3 werden zwei Umsetzungen vorgestellt. Diese werden ebenfalls als Instance Authentication und Middleware Authentication bezeichnet. Die Bedeutung ist jedoch von der in 3.3 zu unterscheiden. In diesem Falle ist keine Authentifizierung, sondern eine Authentisierung gemeint. Der Unterschied liegt darin, dass bei der Authentifizierung aus Sicht des Überprüfers, bei der Authentisierung aus Sicht des Überprüften gehandelt wird. Ein Benutzer authentisiert sich beispielsweise bei einem System, indem er Nachrichten an das System mit seinen Credentials verknüpft. Ein System überprüft die Credentials und authentifiziert dadurch den Benutzer. Im Englischen wird keine Unterscheidung zwischen diesen beiden Begriffen gemacht Instance Authentication Beschreibung Analog zu können ausgehende Web Services eines Prozesses über HTTPS gesichert werden. Je nachdem welche URL aufgerufen wird, sorgt der Server für eine Überprüfung des Zertifikats und eine Verschlüsselung der Daten auf Transportebene. Die Signatur der Daten kann zuvor über den Aufruf eines Web Services erfolgen. Dem Web Service werden dazu die Benutzerinformationen sowie die zu signierenden Daten übergeben. Die zurückgegebenen, signierten Daten bilden die Nutzdaten für den darauf folgenden Web Service Aufruf. Mit Hilfe der Signatur authentisiert sich der Prozess bei dem Web Service. Bewertung Diese Lösung verfügt im Wesentlichen über dieselben Vor- und Nachteile wie die in vorgestellte Lösung zur Absicherung der eingehenden Kommunikation. Entsprechend bietet es sich ebenfalls an, die Anwendung der Sicherheitsmechanismen auf die Middleware zu verlagern. 55

66 Kapitel 3: Sicherheit in BPEL Engines Middleware Authentication Beschreibung Ähnlich wie eingehende Endpunkte können auch ausgehende Endpunkte eines BPEL Prozesses durch die Middleware gesichert werden (siehe 3.3.2). Die Endpunkte müssen dazu wiederum entsprechend konfigurierbar sein. Für die Konfiguration der anzuwendenden Sicherheitsmechanismen können, wie bei den eingehenden Endpunkten, Security Policies verwendet werden. Die Angabe der zu verwendenden Credentials muss differenziert betrachtet werden: Einerseits gibt es Credentials, die von dem aufzurufenden Endpunkt abhängen und daher statisch sind. Andererseits kann es Credentials geben, welche nicht von dem aufzurufenden Endpunkt, sondern von dem Aufrufer des Endpunktes abhängig ist. Da der Aufrufer eines Endpunkts je nach Prozessinstanz und Aktivität variieren kann, sind diese Credentials dynamisch. Im Fall des Beispielprozesses sind die Schlüssel zur Ver- und Entschlüsselung der Nachrichten an die Lieferanten statische Credentials. Der Signaturschlüssel dagegen ist dynamisch. Es sind jedoch auch Anwendungsfälle denkbar, in denen die Signatur mit einem statischen Schlüssel und die Ver- und Entschlüsselung mit dynamischen Schlüsseln erfolgt. Dasselbe gilt für andere Credentials, z.b. Benutzername und Passwort, die bei einem Web Service Aufruf angegeben werden müssen. Diese können ebenfalls statisch oder dynamisch. Statische Credentials können ähnlich wie in Listing 3.3 definiert werden. Für die Bereitstellung von dynamischen Credentials kann ein Callback Mechanismus verwendet werden: Die BPEL Engine erzeugt bei dem Aufruf eines Endpunktes einen Callback Handler und gibt diesen an die Middleware weiter. Der Callback Handler kapselt Informationen über den aufrufenden Benutzer. Benötigt die Middleware für den Absicherung der Nachricht Credentials, die nicht statisch definiert sind, ruft sie den Callback Handler mit Informationen über die fehlenden Credentials auf. Innerhalb des Callback Handlers werden die Credentials von der BPEL Engine ermittelt (z.b. auch durch Anfragen an den jeweiligen Identity Service) und als Ergebnis des Callbacks zurückgegeben. Auf diese Weise muss die Middleware keine Kenntnisse über den Zugriff auf Benutzerinformationen haben. Bewertung Vorteile Trennung von Geschäfts- und Sicherheitslogik. Es können beliebige Verschlüsselungsmechanismen und Authentifizierungsverfahren (z.b. Single Sign-On) eingesetzt werden. Der Aufruf der Endpunkte wird für die BPEL Engine transparent gehalten. Durch den Callback Mechanismus muss die BPEL Engine nicht wissen, welche Credentials von der Middleware benötigt werden. 56

67 Kapitel 3: Sicherheit in BPEL Engines Die Komplexität der Prozessdefinition nimmt ab, da sie sich nur auf die Geschäftslogik beschränkt. Sicherheitsanforderungen können in Form von Security Policies einmal definiert und anschließend auf verschiedene Endpunkte angewandt werden. Gewährleistung von End-to-End Security durch Absicherung der Nachrichten auf Nachrichtenebene (siehe ). Wie anhand der Aufzählung ersichtlich wird, ist diese Lösung der Vorherigen vorzuziehen. 3.8 Auditing sicherheitsrelevanter Ereignisse Auditing stellt eine wichtige Anforderung bei der Ausführung von Geschäftsprozessen dar (siehe ) und spielt auch im Beispielprozess eine Rolle. So sollte etwa im Nachhinein überprüfbar sein, wer welche Bestellung veranlasst und wer sie genehmigt oder abgelehnt hat. Zudem muss eine Archivierung der Auftragsbestätigungen von Lieferanten erfolgen, damit Verbindlichkeit gewährleistet ist (siehe 2.3.2). Neben der Speicherung solcher Nachrichtenereignisse können zudem weitere sicherheitsrelevante Ereignisse, wie z.b. erfolgreiche und fehlgeschlagene Authentifizierungen und Autorisierungen, aufgezeichnet werden. Die Umsetzung dieser Anforderungen kann teilweise durch die Middleware erfolgen. Beispielsweise ist es möglich, dass ein ESB alle Nachrichten an Endpunkte eines Prozesses authentifiziert und autorisiert und die Ergebnisse zusammen mit der Nachricht speichert. Um jedoch eine Zuweisung von Nachrichten zu Prozessinstanzen zu ermöglichen und Autorisierungen innerhalb einer Prozessinstanz aufzeichnen zu können, sollte zusätzlich ein Auditing durch die BPEL Engine stattfinden. Wie bereits in erläutert wurde, implementieren die meisten BPEL Engines ein Event-Modell, durch das sich Komponenten über Ereignisse von Prozessen und Prozessinstanzen informieren lassen können. Werden die Ereignisse persistent gespeichert, entsteht dadurch ein Audit Trail. Auf diesen Mechanismus kann auch zur Speicherung sicherheitsrelevanter Daten und Ereignisse zurückgegriffen werden. Dazu ist jedoch eine Erweiterung des Event-Modells erforderlich. Einerseits müssen bestehende Ereignistypen um Sicherheitsinformationen erweitert, andererseits neue Ereignisse eingeführt werden. Zu den Sicherheitsinformationen, die zusätzlich gespeichert werden, gehören: Signaturen und Credentials innerhalb von Nachrichtenereignissen Benutzerinformationen zu Prozess- und Aktivitätsereignissen Die Anzahl der neuen Ereignisse hängt davon ab, wie die Sicherheitsfunktionen zwischen der Middleware und der BPEL Engine aufgeteilt sind. Erfolgt beispielsweise eine Absicherung der BPEL Engine nach den Konzepten aus (Middleware Authentication) und (Process Authorization), so sollte mindestens das folgende Ereignis hinzugefügt werden: Autorisierung abgelehnt 57

68 Kapitel 3: Sicherheit in BPEL Engines Prozess-ID Instanz-ID Zeitpunkt Name des Partnerlinks Name der Operation Nachricht Benutzerinformationen Die Aufzeichnung des Ereignisses vereinfacht beispielsweise die Erkennung fehlender Berechtigungen. Zudem kann im Fehlerfall beispielsweise eine manuelle Bearbeitung der Prozessinstanz angestoßen werden. Wird die Authentifizierung ebenfalls von der BPEL Engine durchgeführt, sollte für fehlgeschlagene Authentifizierungen ein entsprechendes Ereignis definiert werden. Bei der Speicherung sicherheitsrelevanter Daten sollte darauf geachtet werden, dass die Geheimhaltung sensibler Informationen gewährleistet bleibt. Dies betrifft in erster Linie Passwörter, die innerhalb von eingehenden oder ausgehenden Nachrichten angegeben sind. Es wird vorgeschlagen, dass diese vor einer Speicherung entweder gelöscht oder alternativ verschlüsselt werden. Die Speicherung von Benutzerinformationen ist unproblematisch, sofern diese, wie in vorgeschlagen, lediglich auf den Benutzer eines Identity Services verweisen. 58

69 Kapitel 4: Konzept & Spezifikation Kapitel 4 Konzept & Spezifikation Dieses Kapitel leitet den praktischen Teil der Diplomarbeit ein. Es werden zunächst die Sicherheitsanforderungen ermittelt, die an die zu erweiternde Apache Orchestration Director Engine gestellt werden. Anschließend werden in Kapitel 4.2 Konzepte vorgestellt, welche die Grundlage für die Umsetzung der Anforderungen bilden. Die Absicherung der BPEL Prozesse erfolgt unter anderem durch zusätzliche Konstrukte, die innerhalb der Prozessdefinition verwendet werden. Diese ermöglichen im Wesentlichen einen Zugriff auf den Benutzer- und Sicherheitskontext von Prozessinstanzen (siehe 2.3.2, ). Kapitel 4.3 spezifiziert die neu eingeführten Konstrukte und stellt die Referenz für deren spätere Implementierung dar. Um Instanzen eines Prozesses innerhalb eines Benutzer- und Sicherheitskontextes auszuführen, muss der Prozess in eine Sicherheitsumgebung (Security Domain) eingebettet werden. Die Security Domain bestimmt unter anderem, welche Benutzer sich bei dem Prozess authentifizieren können und welche Richtlinien für den Prozess und dessen Instanzen gelten. Um einen Prozess abzusichern, muss dessen Security Domain von einem Administrator konfiguriert und modifiziert werden können. Dazu wird das Browser Interface der Apache ODE entsprechend erweitert. Kapitel 4.4 spezifiziert die neuen Anwendungsfälle, die bei der Verwendung des Browser Interfaces auftreten. 4.1 Anforderungen Dieses Kapitel beschreibt die Anforderungen bzgl. Sicherheit, die im Rahmen der Diplomarbeit für die BPEL Engine Apache ODE definiert wurden. Die Anforderungen werden dabei textuell und aus Sicht der BPEL Engine sowie deren Benutzergruppen formuliert. Die Benutzergruppen (Akteure) werden dazu zunächst in der folgenden Tabelle spezifiziert. 59

70 Kapitel 4: Konzept & Spezifikation Name Beschreibung Prozessadministrator Ein Anwender, der für das Deployment sowie die Administration von (bestimmten) Prozessen der BPEL Engine zuständig ist. Prozessmodellierer Ein Anwender, der Prozesse modelliert, die von der BPEL Engine ausgeführt werden. Aufrufer Ein Anwender oder ein Prozess, der einen Prozess der BPEL Engine aufruft. Benutzer Die Repräsentation eines (möglichen) Aufrufers innerhalb der BPEL Engine Absicherung der Endpunkte mit WS-Security Ein Prozessadministrator soll sowohl ein- als auch ausgehende Endpunkte und Operationen eines BPEL Prozesses so konfigurieren können, dass diese von der BPEL Engine mit den in WS-Security definierten Mechanismen abgesichert werden. Die Konfiguration der zu verwendenden Mechanismen soll über Security Policies erfolgen (vgl ). Der Prozessadministrator muss daher jedem Endpunkt und jeder Operation eine solche Security Policy zuweisen können. Zusätzlich muss er konfigurieren können, welche Credentials (Schlüssel, Benutzername/Passwort Kombination) die BPEL Engine zur Absicherung der ausgehenden Nachrichten (Request/Response) verwendet. Hierbei soll der Prozessadministrator sowohl statische als auch dynamische (benutzerabhängige) Credentials angegeben können. Die Konfiguration der Endpunkte und Operationen erfolgt über eine grafische Oberfläche. Änderungen an der Einstellungen eines Endpunktes/einer Operation werden von der BPEL Engine ohne ein erneutes Deployment des Prozesses oder einen Neustart der Engine übernommen Authentifizierung Der Prozessadministrator muss die BPEL Engine so konfigurieren können, dass Aufrufer durch die BPEL Engine authentifiziert werden. Die Authentifizierung soll dabei abhängig von der Security Policy des Endpunktes sowie den Benutzern des Prozesses durchgeführt werden. Schreibt die Security Policy vor, dass eingehende Nachrichten Benutzername und Passwort enthalten müssen, soll die BPEL Engine einen Abgleich der Credentials vornehmen. Als Vergleichsdaten dienen hierbei die Benutzerdaten, die dem jeweiligen Prozess über die Benutzer- und Rollenverwaltung zugewiesen wurden (siehe 4.1.3). Ist in der Security Policy festgelegt, dass eingehende Nachrichten digital signiert sein müssen, soll die BPEL Engine für eine Überprüfung der Signaturen sorgen. Hierzu muss der Prozessadministrator dem entsprechenden Endpunkt einen Key Container (z.b. Java Keystores) zuweisen, in dem die Zertifikate von Aufrufern und/oder vertrauenswürdigen Zertifizierungsstellen des Prozesses enthalten sind. 60

71 Kapitel 4: Konzept & Spezifikation Benutzer- und Rollenverwaltung Ein Prozessadministrator muss die Benutzer, Rollen und Rollenzuordnungen von Prozessen verwalten können. Die BPEL Engine verwendet diese Informationen bei der Ausführung des jeweiligen Prozesses um Authentifizierungen, Autorisierungen und Zugriffe auf Benutzereigenschaften durchzuführen. Der Prozessadministrator soll ebenfalls in der Lage sein, die BPEL Engine so zu konfigurieren, dass beliebig viele Prozesse auf dieselbe Benutzerbasis zurückgreifen. Jeder Benutzer und jede Rolle verfügt, innerhalb seines/ihres Definitionsbereichs (Realms), über einen eindeutigen Bezeichner. Der Prozessadministrator kann Benutzer und Rollen über die Angabe eines solchen Bezeichners erzeugen oder löschen. Zudem können einem Benutzer, neben einem Passwort und beliebig vielen Rollen, zusätzliche Eigenschaften zugewiesen werden. Solche Eigenschaften bestehen jeweils aus einem textuellen Bezeichner und einem textuellen Wert und können weitere Informationen über den Benutzer ( -Adressen, Vorname, Nachname, etc.) enthalten. Ist ein Benutzer einem Prozess zugeordnet, muss der dazugehörige Aufrufer in der Lage sein, sich bei einem entsprechend abgesicherten Endpunkt des Prozesses mit seinem Namen und seinem Passwort zu authentisieren. Benutzer und Benutzereigenschaften sowie Rollen und Rollenzugehörigkeiten sollen von dem Prozessadministrator über eine grafische Oberfläche verwaltet werden können. Änderungen an Benutzern, Rollen oder Rollenzugehörigkeiten sollen von der BPEL Engine ohne ein erneutes Deployment des Prozesses oder einen Neustart übernommen werden Zugriffskontrolle und Rechteverwaltung Der Prozessadministrator muss die Zugriffsberechtigungen von Benutzern und Rollen auf Ressourcen der BPEL Engine definieren können. Als Ressourcen werden hierbei die Endpunkt und Operationen von Prozesses angesehen. Sind Zugriffsberechtigungen für einen Endpunkt/eine Operation definiert, so muss die BPEL Engine vor deren Verwendung eine Autorisierung durchführen. Konkret bedeutet dies, dass eingehende Nachricht vor Ausführung der Prozessinstanz, ausgehende Nachrichten vor deren Versand autorisiert werden. Wird die Autorisierung einer ausgehenden Nachricht verweigert, muss die BPEL Engine die Prozessinstanz in einen definierten Fehlerzustand überführen. Die Zugriffssteuerung soll als Mischung aus Discretionary Access Control und Rolebased Access Control realisiert werden: Der Prozessadministrator kann einer Ressource diejenigen Benutzer und Rollen zuweisen, die darauf zugreifen dürfen. Benutzer, Rollen und Ressourcen werden dabei jeweils über ihre eindeutigen Bezeichner referenziert. Eine Unterscheidung zwischen verschiedenen Aktionen, die auf den Ressourcen ausgeführt werden, findet nicht statt. Wiederum sollen Änderungen der Zugriffsrechte über eine grafische Oberfläche möglich sein und von der BPEL Engine unmittelbar übernommen werden. 61

72 Kapitel 4: Konzept & Spezifikation Verwendung des Benutzer- und Sicherheitskontextes in BPEL Einem Prozessmodellierer muss die Möglichkeit gegeben werden, im Rahmen der Prozessdefinition auf Daten und Funktionen des Benutzer- und Sicherheitskontextes einer Prozessinstanz zuzugreifen. So muss es möglich sein, Eigenschaften und Rollenzugehörigkeiten von Benutzern abzufragen. Zudem soll der Prozessmodellierer in der Lage sein, einer Aktivitäten einen Benutzer zuzuweisen. Dabei sollen sowohl Benutzer der Prozessinstanz als auch Benutzer des Prozesses30 angegeben werden können. Wurde einer Aktivität ein Benutzer zugewiesen, so muss die BPEL Engine die Aktivität im Namen des entsprechenden Benutzers ausführen. Wird eine invoke Aktivität im Namen eines Benutzer ausgeführt, so muss der Prozessadministrator den Endpunkt so konfigurieren können, dass Credentials des Benutzers innerhalb der Nachricht platziert werden (vgl ). Der Zugriff auf die Daten und Funktionen des Sicherheits- und Benutzerkontext soll über BPEL Erweiterungen sowie zusätzliche XPath-Funktionen und XPath-Variablen realisiert werden(vgl , 3.5.1, 3.6.1). Die Spracherweiterungen werden in 4.3 genau spezifiziert Auditing sicherheitsrelevanter Daten und Ereignisse Ein Prozessadministrator muss während und nach der Ausführung einer Prozessinstanz überprüfen können, welche Aktivitäten im Namen welches Benutzers ausgeführt wurden. Zudem soll er die digitalen Signaturen eingegangener Nachrichten vorweisen können. Zur Analyse von Richtlinien muss der Prozessadministrator ebenfalls in der Lage sein, Informationen zu fehlgeschlagenen Autorisierungen abzurufen. Die BPEL Engine muss dementsprechend die folgenden sicherheitsrelevanten Daten und Ereignisse im Audit Trail speichern: Benutzerinformationen zu ausgeführten Aktivitäten Digitale Signaturen Fehlgeschlagene Autorisierungen 4.2 Konzepte Dieses Kapitel beschreibt die Konzepte, die zur Umsetzung der Anforderungen verwendet wurden. Die Konzepte bauen auf Erkenntnisse der Kapitel 2 und 3 auf User Context, Security Context und Security Domain Zur Realisierung einer kontextbezogenen Sicherheit werden Prozesse und Aktivitäten von Prozessinstanzen in verschiedene Kontexte eingebettet. Dies wird anhand von Abbildung 4.1 erläutert. 30 Benutzer, die über die Benutzerverwaltung für den jeweiligen Prozess definiert wurden (siehe 4.1.3) 62

73 Kapitel 4: Konzept & Spezifikation Abbildung 4.1: User Context, Security Context und Security Domain Ein abgesicherter Prozess wird im Kontext einer Security Domain (Sicherheitsumgebung) ausgeführt. Innerhalb der Security Domain sind alle Benutzer, Richtlinien und sonstigen sicherheitsrelevanten Daten des Prozesses definiert. Enthält die Security Domain Sicherheitseinstellungen für Endpunkte des Prozesses, werden diese von der BPEL Engine auf die jeweiligen Endpunkte angewendet. Je nach Inhalt der Sicherheitseinstellungen kann die Anwendung beispielsweise zu einer Verschlüsselung und Authentifizierung der Nachrichten des Endpunktes führen. Hinter eingehenden und vor ausgehenden Endpunkten implementiert die BPEL Engine Policy Enforcement Points, an denen die für den jeweiligen Endpunkt geltenden Richtlinien ausgewertet werden. Ist ein Benutzer zum Aufruf eines Prozesses autorisiert, wird eine Instanz des Prozesses ausgeführt. Diese liegt, wie alle ihre Aktivitäten, ebenfalls innerhalb der Security Domain des Prozesses. Einzelne Aktivitäten der Prozessinstanz können im Namen eines Benutzers der Security Domain ausgeführt werden. Alle Benutzerinformationen, auf die die BPEL Engine dabei zugreifen kann, bilden den User Context der Aktivität. Der Security Context bildet eine logische Erweiterung des User Contexts. Er enthält zusätzlich die für den Benutzer geltenden Richtlinien. Policy Enforcement Points, die auf Ebene der Aktivitäten implementiert werden, nutzen die Daten des Security Contexts zur Autorisierung des Benutzers Security Services Die Verwaltung von sicherheitsrelevanten Daten sowie die Implementierung von Sicherheitsmechanismen wird nicht fest in die BPEL Engine integriert. Stattdessen werden die Daten und Funktionen von Sicherheitsdiensten (Security Services) bereitgestellt und der BPEL Engine ein Zugriff auf diese Dienste ermöglicht (vgl ). Die Funktionalität wird dabei auf die drei folgenden Arten von Diensten verteilt: Identity Services, Authorization Services und Endpoint Settings Services. Jedem Prozess können jeweils ein Authorization und Endpoint Setting Service, sowie beliebig viele Identity Services zugeordnet werden. Die Dienste bieten einen Zugriff auf alle Benutzer, Rol63

74 Kapitel 4: Konzept & Spezifikation len, Endpunktkonfigurationen und Sicherheitsfunktionen, die zur Absicherung des Prozesses benötigt werden. Damit bilden sie zusammengenommen die Security Domain des Prozesses. Die BPEL Engine, die den Prozess bereitstellt, greift an folgenden Stellen auf Daten und Funktionen der Dienste zu und benutzt diese zur Absicherung des Prozesses: Endpunkte des Prozesses werden zum Bereitstellungs- oder Aufruf-Zeitpunkt entsprechend der Einstellungen konfiguriert, die von einem Endpoint Settings Service vorgegeben sind. Zur Authentifizierung und zum Zugriff auf Benutzerinformationen werden entsprechende Funktionen der Identity Services aufgerufen. An Policy Enforcement Points wird durch den Aufruf des Authorization Services eine Zugriffskontrolle durchgeführt User References Wird eine Prozessinstanz ausgeführt, speichert die BPEL Engine Daten über die daran beteiligten Benutzer (siehe User Data, Abbildung 4.2). Diese Daten beinhalten jedoch nicht alle Informationen, die zu den entsprechenden Benutzern verfügbar sind. Stattdessen können die gespeicherten Daten als Referenz auf den Benutzer innerhalb der Security Domain angesehen werden (vgl ). Alle Benutzerinformationen, auf die über diese Referenzen zugegriffen werden kann, wie z.b. Eigenschaften oder Credentials, bilden den Benutzerkontext der Prozessinstanz. Es werden Spracherweiterungen implementiert, mit denen innerhalb der Prozessdefinition ein Zugriff auf den Benutzerkontext möglich ist (siehe 4.3). Abbildung 4.2: User References Bei Abfragen von Benutzereigenschaften ermittelt die BPEL Engine zunächst, ob die Eigenschaft in den gespeicherten Benutzerdaten enthalten ist. Ist dies nicht der Fall, löst die BPEL Engine die Referenz auf den Benutzer auf und fragt die Eigenschaft von dem Identity Service des jeweiligen Benutzers ab. Dieser Mechanismus ermöglicht es beispielsweise, Eigenschaften eines Benutzern innerhalb der Prozessdefinition zu überschreiben. Wird die Security Domain eines Prozesses geändert, kann es sein, dass gespeicherte Benutzerdaten unbrauchbar werden, da sie mit keinem Benutzer der Security Domain mehr assoziiert sind. In diesem Fall müssen durch den Prozessadministrator entsprechende Modifikationen der Benutzerdaten durchgeführt werden. Alternativ können Zugriffe auf 64

75 Kapitel 4: Konzept & Spezifikation ungültige Benutzerreferenzen auch innerhalb der Prozessdefinition abgefangen werden (siehe Fehler unknownuser, 4.3.2) Service Abstraction Die Speicherung von Benutzer- und Rolleninformationen kann auf sehr unterschiedliche Weise erfolgen. Die Informationen können beispielsweise in Benutzerdatenbanken, Dateien oder LDAP-Verzeichnissen gespeichert sein. Dienste, welche die Daten solcher User Registries verwalten und bereitstellen, besitzen häufig unterschiedliche Schnittstellen oder sind über verschiedene Protokolle erreichbar. Dasselbe gilt für Dienste, die andere sicherheitsrelevante Daten und Funktionen zur Verfügung stellen. Abbildung 4.3: Service Abstraction Damit die BPEL Engine einheitlich auf Daten und Funktionen solcher Dienste zugreifen kann, werden Schnittstellen definiert, die die Funktionalität der unterschiedlichen Arten von Sicherheitsdiensten spezifizieren (Common Interface, Abbildung 4.3). Dienste, die diese Schnittstellen implementieren, können in die BPEL Engine eingebunden werden. Da die Dienste aus Sicht der BPEL Engine auf die implementierte Schnittstelle reduziert werden, spricht man von Service Abstraction (vgl. 2.1). Durch Verwendung dieses Konzeptes ist es möglich, unterschiedlichste Realisierungen von Sicherheitsdiensten in die BPEL Engine einzubinden. Im Wesentlichen können die Realisierungen dabei in folgende Kategorien unterteilt werden: Dienste, die Daten selbst verwalten und die Logik der Schnittstellenfunktionen implementieren (siehe Authorization Service X in Abbildung 4.3). Dienste, die Daten und Funktionen von externen Diensten (wie z.b. einem Web Service) bereitstellen (siehe Authorization Service Y). Beide Varianten haben ihre Vor- und Nachteile und sind jeweils für unterschiedliche Anwendungsfälle geeignet. Beispielsweise bietet sich die erste Variante an, wenn die Sicherheitsdaten eines Prozess eher lokalen und/oder temporären Charakter haben. Die Daten können in diesem Fall etwa in einer dem Prozess zugeordneten Datei gespeichert werden. Ein entsprechend implementierter Dienst liest die Daten der Datei ein und stellt 65

76 Kapitel 4: Konzept & Spezifikation diese der BPEL Engine zur Verfügung. Die zweite Variante eignet sich dagegen, wenn zur Absicherung eines Prozesses auf bestehende Dienste, wie etwa Web Services, zurückgegriffen werden soll. Bei der Auswahl der Dienste kann auch die Performanz eine Rolle spielen. Erfordert die Ausführung eines Prozesses etwa eine Vielzahl an Aufrufen der Sicherheitsdienste (z.b. durch Policy Enforcement Points), können diese Aufrufe bei Verwendung externer Dienste viel Zeit beanspruchen. Handelt es sich um einen synchronen Prozess, treten dadurch unter Umständen Timeouts auf. In diesem Fall bietet sich die Verwendung von Diensten an, die direkt auf Daten zugreifen oder diese im Speicher halten. Alternativ kann ein Sicherheitsdienst auch so implementiert werden, dass er Daten eines externen Dienstes cached Security Domain Composition Durch die Gruppierung der Sicherheitsfunktionalitäten in verschiedenen Diensten ist es möglich, die Security Domain eines Prozesses individuell zusammenzustellen. Dadurch ist es beispielsweise möglich, verschiedenen Prozesse dieselben Benutzer und Rollen, jedoch unterschiedliche Richtlinien zuzuweisen. Zudem können die Security Domains verschiedener BPEL Engines miteinander verknüpft werden. Dies wird in Abbildung 4.4 illustriert: Abbildung 4.4: Security Domain Composition Process 1 wird auf der BPEL Engine Engine 1, Process 2 und Process 3 auf der BPEL Engine Engine 2 ausgeführt. Process 1 und Process 2 greifen über Identity Services auf Benutzer und Rollen desselben LDAP Verzeichnisses zu. Während der Identity Service von Process 2 dazu direkt mit dem (lokalen) LDAP Server kommuniziert, geschieht dies bei Process 1 indirekt über einen externen Dienst. Die Benutzer und Rollen des LDAP Verzeichnisses liegen damit in der Security Domain beider Pro66

77 Kapitel 4: Konzept & Spezifikation zesse. Interagieren die Prozesse miteinander, können Benutzer einfach zwischen den Prozessen übergeben werden. Auf dieselbe Art können auch Richtlinien und Endpunkteinstellungen aus denselben Datenquellen, wie z.b. Datenbanken oder Dateien, in verschiedene Prozesse eingebunden werden. Gleichzeitig ist es jedoch auch möglich, für jeden Prozess eine eigene Datenquellen anzugeben. Die Richtlinien von Prozessen können dadurch beispielsweise in separaten Dateien angegeben werden Centralized Security Management Die Sicherheit eines Prozesses ist durch die Gesamtheit der Daten bestimmt, auf die die Sicherheitsdienste des Prozesses direkt oder indirekt zugreifen. Diese Daten beschreiben Benutzer, Richtlinien und andere Sicherheitseinstellungen des Prozesses. Um die Sicherheit anzupassen, müssen dementsprechend Änderungen an den Daten vorgenommen werden. Damit diese nicht von Hand durchgeführt werden müssen, bieten die Schnittstellen der Sicherheitsdienste (siehe 4.2.4) Funktionen zur Verwaltung der Daten an. Implementieren die Realisierungen der Schnittstellen diese Funktionen, so wird eine zentrale Konfiguration der Sicherheitseinstellungen über die BPEL Engine ermöglicht. Die BPEL Engine kann dazu beispielsweise einen Web Service mit den entsprechenden Management Funktionen (createuser, deleteuser,...) bereitstellen. Wird eine Funktion aufgerufen, ermittelt die BPEL Engine den zuständigen Sicherheitsdienst und ruft die entsprechende Funktion des Dienstes auf Security Descriptor Die Sicherheitsdienste eines Prozesses definieren dessen Security Domain. Damit die BPEL Engine einen Prozess innerhalb einer Security Domain ausführen kann, muss entsprechend definiert sein, welche Sicherheitsdienste dem Prozess zugeordnet sind. Dies erfolgt innerhalb einer Datei, die im Folgenden als Security Descriptor bezeichnet wird. Der Security Descriptor enthält alle Informationen, die zur Erzeugung der Sicherheitsdienste einer Security Domain benötigt werden. Einem Prozess wird über einen Security Descriptor diejenige Security Domain zugewiesen, in der er von der BPEL Engine ausgeführt werden soll. Dies erfordert wiederum die Zuweisung eines Security Descriptors zu einem Prozess. Hierzu werden die folgenden Möglichkeiten angeboten: Der Security Descriptor wird als security.xml im Deployment-Verzeichnis des Prozesses abgelegt und dem Prozess damit implizit zugewiesen. Der Pfad der Security Descriptors wird im Deployment Descriptor des Prozesses explizit angegeben (siehe Listing 4.1). In diesem Fall ist es möglich, für mehrere Prozesse denselben Security Descriptor zu verwenden und dadurch redundante Dateien zu vermeiden. Wurde einem Prozess ein Security Descriptor zugewiesen, lädt die BPEL Engine den Security Descriptor und erzeugt daraus die Security Domain des Prozesses. Haben Änderungen an der Security Domain Auswirkungen auf den Security Descriptor (z.b. durch den Austausch von Sicherheitsdiensten), wird dieser entsprechend aktualisiert. 67

78 Kapitel 4: Konzept & Spezifikation 1 <deploy xmlns="http://www.apache.org/ode/schemas/dd/2007/03" 2 xmlns:sec="http://www.apache.org/ode/security" 3 <process> 4 [...] 5 <sec:security-descriptor path="mysecuritydescriptor.xml"/> 6 </process> 7 [...] 8 </deploy> Listing 4.1: Angabe des Security Descriptors im Deployment Descriptor Zugleich überwacht die BPEL Engine, ob manuelle Änderungen an der Datei vorgenommen werden. Ist dies der Fall, werden die betroffenen Prozesse entsprechend aktualisiert Endpoint Configuration Die Sicherheitseinstellungen von Endpunkten und deren Operationen werden von Endpoint Settings Services verwaltet. Bei der Bereitstellung oder dem Aufruf einer Operation fordert die BPEL Engine die jeweiligen Einstellungen bei dem zuständigen Dienst an und konfiguriert damit die Middleware (analog zu und 3.7.2). Um einer Operation Sicherheitseinstellungen zuzuweisen oder diese abzufragen, muss die Operation referenziert werden. Dies kann auf zwei Arten geschehen: Die Operation wird über die Konkatenation des Web Service Namens und des Operationsnamens referenziert (z.b. {http://org.sales}salesservice/myoperation) Die Operation wird über die Konkatenation der Endpunktadresse und des Operationsnamens referenziert (z.b. In diesem Fall ist es möglich, Operationen je nach Adresse des Endpunktes mit unterschiedlichen Sicherheitseinstellungen (Policies, Credentials) aufzurufen. Verfügt der Endpoint Settings Service über Sicherheitseinstellungen für beide Referenzierungsvarianten, haben die Einstellungen mit der Endpunktadresse Priorität. Um Sicherheitseinstellungen für alle Operationen eines Endpunktes festzulegen, kann alternativ lediglich der Name des Web Services oder die Adresse des Endpunktes (ohne den Operationsnamen) als Ziel der Sicherheitseinstellungen angegeben werden. Sind für eine bestimmte Operation sowohl Einstellungen für die Operation, als auch für deren Endpunkt vorhanden, haben die Operationseinstellungen Priorität. Über die Sicherheitseinstellungen kann angegeben werden, welche Security Policy für die referenzierte Operation gelten soll. Die BPEL Engine wendet die Security Policy dann auf den entsprechende Operation an. Ist keine Policy angegeben, sollte bereits eine Policy in der WSDL Definition enthalten sein, die die BPEL Engine zum Aufruf des Web Services verwendet. Zusätzlich zur Security Policy werden in den Sicherheitseinstellungen die Credentials spezifiziert, die bei einem Nachrichtenaustausch verwendet werden sollen. Credentials werden über eine Struktur definiert, die aus verschiedenen Feldern besteht. Die Werte einiger Felder sind dabei nur bei bestimmten Policies relevant. Alle Felder sowie deren Bedeutungen und Relevanz werden in der folgenden Tabelle aufgelistet. 68

79 Kapitel 4: Konzept & Spezifikation Feld Bedeutung Rel. My Username Der Name des Aufrufers. UT31 My Password Das Passwort des Aufrufers. UT My Keystore Ein Keystore, der die privaten Schlüssel enthält, die auf Prozessseite verwendet werden. My Key Alias 32 Der Alias eines privaten Schlüssels aus My Keystore, mit SG 33 DC dem Nachrichten signiert und entschlüsselt werden sollen. My Key Password Das Passwort des Schlüssels My Key Alias Partner Keystore Ein Keystore, der die Zertifikate zu privaten Schlüsseln ent- EC34 hält, die auf Seite des Partners verwendet werden können SC35 Partner Key Alias Der Alias eines Zertifikates aus Partner Keystore, mit dem EC Nachrichten verschlüsselt werden sollen. Credentials, die für ausgehende Operationen definiert werden, können statt fester Werte (wie z.b. My Username= Hans ) auch Platzhalter enthalten. Ein Platzhalter beginnt mit einem $ -Zeichen, gefolgt von dem Namen einer Benutzereigenschaft (z.b. givenname ). Sind bei dem Aufruf eines Web Service Aufrufs Platzhalter in den verwendeten Credentials angegeben, löst die BPEL Engine diese zunächst auf. Ist beispielsweise der Platzhalter $givenname im Feld My Username angegeben, so ermittelt die BPEL Engine den Wert der Eigenschaft givenname des aktuellen Benutzers und verwendet diesen anstelle des Platzhalters. Entsprechend wird im UsernameToken der ausgehenden Nachricht der Vorname des Aufrufers als Benutzername angegeben. Durch den Platzhalter-Mechanismus ist es möglich, sowohl statische als auch dynamische Credentials für einen Web Service Aufrufe anzugeben (siehe 3.7.2). Zudem können ausgehende Nachrichten abhängig vom aktuellen Benutzer signiert werden. Dazu müssen lediglich zwei Benutzereigenschaften festgelegt werden (z.b. keyalias und keypassword ), in denen der Alias und das Passwort angegeben sind, über die auf den privaten Schlüssel des Benutzer zugegriffen werden kann. Sind in den Credentials einer Operation Platzhalter für die entsprechenden Benutzereigenschaften eingetragen (z.b. My Key Alias= $keyalias, My Key Password= $keypassword ), erfolgt eine Signatur mit dem privaten Schlüssel des Benutzers. In einigen Anwendungsfällen kann es sein, dass der Web Service Aufruf eines bestimmten Benutzer mit alternativen Credentials erfolgen muss. Ein Beispiel hierfür wäre, wenn ein Benutzer bei einem aufzurufenden Web Service über eine andere Benutzerkennung oder einen anderen privaten Schlüssel verfügt. Für diesen Fall kann in den Sicherheitseinstellungen einer ausgehenden Operationen eine Zuweisung von Benutzern zu Credentials angegeben werden. Wird die entsprechende Operation aufgerufen, dann überprüft die BPEL Engine zunächst, ob für den aktuellen Benutzer eigene Credentials 31 Relevant, falls ausgehende Nachrichten über ein UsernameToken verfügen müssen Relevant, falls ausgehende Nachrichten signiert werden müssen 33 Relevant, falls eingehende Nachrichten entschlüsselt werden müssen 34 Relevant, falls ausgehende Nachrichten verschlüsselt werden müssen 35 Relevant, falls Signaturen eingehender Nachrichten überprüft werden müssen 32 69

80 Kapitel 4: Konzept & Spezifikation spezifiziert sind. Ist dies der Fall, gibt sie die Credentials an die Middleware weiter. Ansonsten werden die Standard-Credentials verwendet. 4.3 Spracherweiterungen Für die Absicherung eines BPEL Prozesses kann es nötig sein, innerhalb der Prozessdefinition auf Daten und Funktionen sowohl des Benutzer- und Sicherheitskontext der Prozessinstanz, als auch der Security Domain des Prozesses zuzugreifen. In diesem Kapitel werden Spracherweiterungen spezifiziert, die dies ermöglichen. In diesem Zusammenhang werden drei unterschiedliche Erweiterungsmechanismen eingesetzt: BPEL Erweiterungsattribute (Extension Attributes) Benutzerdefinierte XPath-Variablen Benutzerdefinierte XPath-Funktionen Darüber hinaus werden Datentypen definiert, die zur Verwendung der Erweiterungen nötig sind. Durch den Einsatz der Erweiterungen können zusätzliche Fehlerfälle bei der Ausführung einer Prozessinstanz auftreten. Um in BPEL auf die Fehler individuell reagieren zu können, werden diese in spezifiziert. Soweit nicht anderes angegeben, werden Erweiterungen dieses Kapitel innerhalb des Namespaces definiert Typen Um einheitlich auf Benutzer und deren Eigenschaften zugreifen zu können, müssen die zu einem Benutzer gespeicherten Informationen typisiert sein. Da BPEL zur Typisierung XML Schema verwendet, werden die folgenden Typen ebenfalls in XML Schema ausgedrückt. Die Typdefinitionen können dann beispielsweise bei der Deklaration von Variablen in BPEL verwendet werden. Property Property Elemente enthalten Eigenschaften, bestehend aus einem eindeutigen Bezeichner und einem textuellen Wert. 1 <xs:element name="property"> 2 <xs:complextype> 3 <xs:simplecontent> 4 <xs:extension base="xs:string"> 5 <xs:attribute name="id" type="xs:name" use="required"/> 6 </xs:extension> 7 </xs:simplecontent> 8 </xs:complextype> 9 </xs:element> Listing 4.2: XML Schema des Elements Property 70

81 Kapitel 4: Konzept & Spezifikation User User Elemente enthalten Informationen über Benutzer. Dazu gehören mindestens der Benutzernamen und der Name des Realms, in dem der Benutzer definiert ist. Zusätzlich können beliebig viele Property Elemente enthalten sein, die Eigenschaften des Benutzers angeben. 1 <xs:element name="user"> 2 <xs:complextype> 3 <xs:sequence> 4 <xs:element minoccurs="0" maxoccurs="unbounded" type="property"/> 5 </xs:sequence> 6 <xs:attribute name="id" type="xs:name" use="required"/> 7 <xs:attribute name="realm" type="xs:name" use="required"/> 8 </xs:complextype> 9 </xs:element> Listing 4.3: XML Schema des Elements User UserContext Elemente des Typs UserContext enthalten Informationen über einen Benutzerkontext (z.b. einer Aktivität). Ein Benutzerkontext besteht lediglich aus einem User Element, in dem ein Benutzer definiert wird (vgl ). 1 <xs:complextype name="usercontext"> 2 <xs:sequence> 3 <xs:element name="user" ref="user"/> 4 </xs:sequence> 5 </xs:complextype> Listing 4.4: XML Schema des Typs UserContext Fehler Die Fehlerbehandlung von BPEL Engines basiert auf Faults (Fehlern) und Fault Handlern. Wird bei der Ausführung einer Aktivität ein Fehler ausgelöst, können Fault Handler, die in den übergeordneten Scopes der Aktivität definiert wurden, eine Fehlerbehandlung durchführen. Ein Fault Handler kann dabei nur für eine bestimmte Art von Fehlern zuständig sein. Die Fehlerart wird in BPEL über einen qualifizierten Namen, den Fehlernamen (faultname) ausgedrückt. Die Erweiterung der BPEL Engine um Sicherheitsmechanismen hat zur Folge, dass zusätzliche Fehlerfälle auftreten können. Für diese Fehlerfälle werden die folgenden Fehlernamen definiert. unknownuser Wird ausgelöst, wenn auf Eigenschaften oder Rollen eines Benutzers zugegriffen werden soll, der in der Security Domain des Prozesses nicht definiert ist. usernotavailable Wird ausgelöst, wenn innerhalb einer Aktivität auf den Benutzerkontext zugegriffen werden sollen, dieser jedoch nicht existiert. 71

82 Kapitel 4: Konzept & Spezifikation authorizationdenied Wird ausgelöst, wenn eine Autorisierung während der Ausführung einer Prozessinstanz fehlschlägt Erweiterungsattribute Der BPEL Standard erlaubt die Erweiterung aller (XML-)Elemente um beliebige Attribute. Solche Attribute können beispielsweise verwendet werden, um zusätzliche Aspekte, wie z.b. nicht-funktionale Anforderungen, einer Aktivität zu definieren. Die im Folgenden spezifizierten Erweiterungsattribute ermöglichen die Deklaration verschiedener Sicherheitsanforderungen von Aktivitäten. Die BPEL Engine wird so erweitert, dass sie die entsprechenden Sicherheitsmechanismen durchführt. usercontext Das usercontext Attribut kann innerhalb von Inbound Message Activities (IMA) verwendet werden (vgl ). Der Wert des Attributs muss dem Namen einer Variablen des Typs UserContext entsprechen. Ist dies nicht der Fall, wird bereits bei der Kompilierung des Prozesses eine entsprechende Fehlermeldung ausgegeben. Ansonsten speichert die BPEL Engine die Benutzerinformationen des dazugehörigen Web Service Aufrufs in der angegebenen Variablen. Sind keine Benutzerinformationen mit dem Web Service Aufruf verknüpft, wird der Variablen null zugewiesen. runas Mit dem runas Attribut können Aktivitäten eines Prozesses bestimmten Benutzern zugewiesen werden. Das Attribut kann dazu innerhalb der BPEL Elemente invoke, assign und scope platziert werden (vgl ). Der Wert des Attributs kann auf zwei verschiedene Arten auf einen Benutzer verweisen. Zum einen kann als Wert der Namen einer Variablen des Typs UserContext angegeben werden. In diesem Fall wird der Aktivität derjenige Benutzer zugewiesen, der innerhalb der Variablen gespeichert ist. Die zweite Möglichkeit besteht darin, einen konstanten Benutzernamen anzugeben. Der Benutzername muss dazu in einfachen Anführungszeichen (') eingeschlossen sein. Er kann entweder qualifiziert oder unqualifiziert angegeben werden. Bei unqualifizierten Angaben wird versucht, den Benutzer über die Identity Services des Prozesses eindeutig aufzulösen. Existiert der angegebene Benutzer nicht oder kann der Benutzername nicht eindeutig einem Benutzer zugewiesen werden, löst die BPEL Engine den Fehler unknownuser aus. Ist des Wert Attributes leer oder enthält die zugewiesene Variable keine Benutzerinformationen, wird der Aktivität kein Benutzer zugewiesen. Existiert das Attribut nicht, wird der Aktivität der Benutzer des Scopes zugewiesen, in dem die Aktivität enthalten ist. Handelt es sich bei der Aktivität um die Root Activity, wird ihr der Benutzer der Prozessinstanz zugewiesen. runasstarter Das Attribut runasstarter kann innerhalb des process Elements platziert werden und gibt an, ob die Prozessinstanz demjenigen Benutzer zugeordnet werden soll, dessen 72

83 Kapitel 4: Konzept & Spezifikation Aufruf zur Erzeugung der Prozessinstanz geführt hat (vgl ). Ist der Wert des Attribut no, wird der Prozessinstanz kein Benutzer zugewiesen. Existiert das Attribut nicht oder ist der Wert yes, weist die BPEL Engine der Prozessinstanz den entsprechenden Benutzer zu. Kann der Aufruf, der zur Erzeugung der Prozessinstanz geführt hat, keinem Benutzer zugeordnet werden, wird auch der Prozessinstanz kein Benutzer zugewiesen. rolesallowed Das rolesallowed Attribut kann innerhalb der BPEL Elemente receive, onmessage, onevent, invoke, assign und scope zur Durchführung einer rollen-basierten Zugriffskontrolle verwendet werden. Der Wert des Attributes gibt die Rollen an, denen der Zugriff auf die jeweilige Aktivität erlaubt ist. Rollen werden dabei über ihren Namen angegeben und mit Kommata (,) getrennt. Ist das Attribut innerhalb einer Inbound Message Activity angegeben, muss die Rollenüberprüfung vor Ausführung der Prozessinstanz stattfinden. Es werden dabei die Rollen des Aufrufers der Aktivität überprüft. Kann der Aufruf keinem Benutzer zugewiesen werden oder verfügt der Aufrufer über keine der angegebenen Rollen, löst die BPEL Engine das Ereignis ProcessAuthorizationDeniedEvent aus. In diesem Fall wird keine Prozessinstanz erzeugt. Ist das Attribut innerhalb der Aktivitäten invoke, assign oder scope angegeben, wird eine Rollenüberprüfung für den Benutzer vorgenommen, der der Aktivität zugeordnet ist (siehe runas, runasstarter). Falls die Aktivität keinem Benutzer zugeordnet ist, wird der Fehler usernotavailable ausgelöst. Verfügt der Benutzer über keine der angegebenen Rollen, wird der Fehler authorizationdenied ausgelöst. Zusätzlich wird das Ereignis ActivityAuthorizationDeniedEvent gesendet. Enthält eine Aktivität sowohl das rolesallowed, als auch das runas Attribut, so hat das rolesallowed Attribute Vorrang vor dem runas Attribut. D.h. die Benutzerzuweisung wird erst nach der Rollenüberprüfung durchgeführt. initialvalue Das initialvalue Attribut dient zum Initialisieren von Variablen über den Deployment Descriptor. Es ist im Namespace angegeben und kann innerhalb von variable Elementen angegeben werden. Der Wert des Attributes muss den qualifizierten Namen einer Eigenschaft beinhalten, die im Deployment Descriptor definiert ist. Das Attribut kann beispielsweise verwendet werden, um Variablen vom Typ UserContext zu initialisieren und damit über den Deployment Descriptor die Benutzer der Prozessinstanzen festzulegen. 73

84 Kapitel 4: Konzept & Spezifikation 1 <deploy xmlns="http://www.apache.org/ode/schemas/dd/2007/03"> 2 <process name="myprocess"> 3 <property name="sec:servicecaller"> 4 <user xmlns="http://www.apache.org/ode/security" 5 id="userxyz" realm="org.users"> 6 <property id="password">4wcfw32dwe</property> 7 </user> 8 </property> 9 [...] 10 </process> 11 </deploy> Listing 4.5: Definition von Benutzern im Deployment Descriptor Listing 4.5 zeigt etwa, wie ein Benutzer innerhalb des Deployment Descriptors als Wert der Prozesseigenschaft servicecaller definiert wird (Zeile 3-8). In der dazugehörigen Prozessdefinition (Listing 4.6) wird diese Prozesseigenschaft bei der Deklaration der Variablen caller über das Attribut initialvalue referenziert (Zeile 7). Die BPEL Engine initialisiert dementsprechend die Variable mit dem oben angegebenen Benutzer. Dies führt dazu, dass die invoke Aktivität in Zeile 12 im Namen des Benutzer ausgeführt wird. 1 <process xmlns=".../process/executable" 2 xmlns:ode="http://www.apache.org/ode/type/extension" 3 xmlns:sec="http://my-bpel-engine/security" name="myprocess"> 4 [...] 5 <variables> 6 <variable name="caller" type="sec:usercontext" 7 ode:initialvalue="sec:servicecaller"/> 8 [...] 9 </variables> 10 <sequence> 11 [...] 12 <invoke [...] sec:runas="caller"/> 13 </sequence> 14 </process> Listing 4.6: Initialisierung einer Variablen mit Benutzerinformationen XPath-Variablen Innerhalb von XPath-Ausdrücken kann über den '$'-Operator auf Variablen des aktuellen Kontextes der Prozessinstanz zugegriffen werden. Der Kontext ist dabei abhängig von der Aktivität und den Scopes, innerhalb derer der XPath-Ausdruck ausgeführt wird. Um zusätzlich auf die Benutzerinformationen dieses Kontextes zugreifen zu können, werden die folgenden XPath-Variablen definiert. $starter Eine Variable vom Typ UserContext, welche die Benutzerinformationen des Erzeugers der Prozessinstanz beinhaltet. Wurde die Prozessinstanz keinem Benutzer zugewiesen, ist der Wert der Variablen null. $user Eine Variable vom Typ UserContext, welche die Benutzerinformationen desjenigen Benutzers enthält, in dessen Namen die aktuelle Aktivität ausgeführt wird. Wird beispielsweise eine assign Aktivität im Namen eines bestimmten Benutzers ausgeführt (z.b. 74

85 Kapitel 4: Konzept & Spezifikation durch Verwendung des runas Attributs), enthalten alle darin vorkommenden user Variablen die Informationen dieses Benutzers XPath-Funktionen Die von Apache ODE verwendete XPath 2.0 Engine erlaubt eine Erweiterung um benutzerdefinierte Funktionen. Solche Funktionen werden verwendet, um einen einfachen Zugriff auf Funktionalitäten des Sicherheitskontextes, in dem der jeweilige XPath-Ausdruck ausgewertet wird, zu ermöglichen. Die Apache ODE wird um die folgenden XPath-Funktionen erweitert. getuserproperty(propertyname, usercontext?) Die Funktion getuserproperty gibt den Wert einer bestimmten Benutzereigenschaft zurück36. Der erste Parameter muss ein String sein, der den Namen der abzufragenden Eigenschaft enthält. Der zweite Parameter ist optional und spezifiziert den Benutzer, dessen Eigenschaft abgefragt werden soll. Der Benutzer kann entweder über eine Variable vom Typ UserContext oder einen String mit dem qualifizierten oder unqualifizierten Namen des Benutzer angegeben werden. Wird ein nicht qualifizierter Benutzername angegeben, versucht die BPEL Engine den Benutzer bei den Identity Services des Prozesses aufzulösen. Gelingt dies nicht, wird der Fehler unknownuser ausgelöst. Falls der Parameter nicht angegeben ist, wird der aktuelle Benutzer verwendet37. Ist der Aktivität, innerhalb derer der XPath-Ausdruck ausgeführt wird, kein Benutzer zugeordnet, wird der Fehler usernotavailable ausgelöst. Der Wert der Benutzereigenschaft wird auf folgende Weise ermittelt: Zunächst wird die Eigenschaft in den übergebenen (bzw. den aktuellen) Benutzerinformationen gesucht. Ist sie dort nicht vorhanden, wird versucht, die Eigenschaft bei dem Identity Service des Benutzer abzufragen. Kann der Benutzer dabei nicht aufgelöst werden, wird der Fehler unknownuser ausgelöst. Ansonsten wird der Wert der Eigenschaft zurückgegeben. Existiert die Eigenschaft nicht, ist das Ergebnis der Funktion null. hasrole(rolename, usercontext?) Führt eine Rollenüberprüfung bei dem aktuellen oder einem bestimmten Benutzer durch. Der erste Parameter muss ein String sein, der den Namen der zu überprüfenden Rolle enthält. Der zweite Parameter ist optional und spezifiziert den Benutzer. Die Verwendung dieses Parameters sowie die Fehlerfälle entsprechen denen der Funktion getuserproperty. Ist der Benutzer im Besitz der angegebenen Rolle, wird true zurückgegeben. Ansonsten ist das Ergebnis der Funktion false. hasaccess(resource, usercontext?) Mit der Funktion hasaccess kann überprüft werden, ob ein Benutzer über die Zugriffsberechtigung auf eine bestimmte Ressource verfügt. Der erste Parameter muss ein String sein, der den Namen der zu Ressource enthält. Der zweite Parameter ist optional Die Funktion ist vergleichbar mit der Funktion getattributevalue aus Der Aufruf ist damit äquivalent zum Aufruf getuserproperty(propertyname, $user) 75

86 Kapitel 4: Konzept & Spezifikation und spezifiziert den Benutzer. Die Verwendung dieses Parameters sowie die Fehlerfälle entsprechen denen der Funktion getuserproperty. Ist der Benutzer zum Zugriff auf die angegebene Ressource berechtigt, wird true zurückgegeben. Ansonsten ist das Ergebnis der Funktion false. Die Entscheidung hängt dabei von den Sicherheitseinstellungen des jeweiligen Prozesses ab. Ist die Sicherheit für den Prozess global deaktiviert oder ist dem Prozess kein Authorization Service zugeordnet, wird immer true zurückgegeben. Ansonsten ist die Entscheidung abhängig von den Richtlinien des Authorization Services. 4.4 Anwendungsfälle Die Definition und Konfiguration der Security Domain von Prozessen erfolgt über das Browser Interface von Apache ODE, welches im Zuge der Diplomarbeit erweitert wurde. Im Folgenden wird anhand von Anwendungsfällen die Funktionalität dieser Erweiterungen beschrieben. Die Anwendungsfälle sind dabei in die Unterbereiche Allgemein, Benutzerverwaltung, Zugriffsrechteverwaltung und Endpunkteverwaltung unterteilt. Als Akteur tritt in allen Anwendungsfällen der Prozess-Administrator auf Allgemeine Anwendungsfälle Dieses Kapitel beschreibt allgemeine Anwendungsfälle, die keinem Unterbereich zugeordnet werden können. Anwendungsfall 1: Sicherheitseinstellungen eines Prozess anzeigen Vorbedingung: Es wird die Seite Security Settings angezeigt (siehe Abbildung A1). Regulärer Ablauf: 1. Der Akteur wählt in der Auswahlliste den Namen des Prozesses aus, dessen Sicherheitseinstellungen angezeigt werden sollen. Nachbedingung: Die Sicherheitseinstellungen des ausgewählten Prozesses werden angezeigt. Alternative Abläufe: Zu 1. Der Akteur wählt in der Auswahlliste den Eintrag Select a Process aus. Daraufhin werden keine Sicherheitseinstellungen mehr angezeigt. Anwendungsfall 2: Sicherheit aktivieren/deaktivieren Vorbedingung: Es werden die Sicherheitseinstellungen eines Prozesses angezeigt. Regulärer Ablauf: 1. Der Akteur klickt auf das Kontrollkästchen Security Disabled / Security Enabled. 76

87 Kapitel 4: Konzept & Spezifikation Nachbedingung: Der Text der Schaltfläche ändert sich von Security Disabled / Security Enabled zu Security Enabled / Security Disabled. Alle Sicherheitseinstellungen des Prozesses werden aktiviert/deaktiviert. Die Deaktivierung der Sicherheit hat folgende Auswirkungen: Die Sicherheit der Endpunkte wird deaktiviert. Security Policies, die Endpunkten über die Sicherheitseinstellungen zugewiesen wurden, werden entfernt. Die Verschlüsselung, Authentifizierung und Autorisierung wird deaktiviert. Die Funktion der Erweiterungsattribute aus wird deaktiviert Anwendungsfälle der Benutzerverwaltung Die Benutzer und Rollen eines Prozesses werden von Identity Services bereitgestellt. Über die Konfigurationsoberfläche müssen diese Identity Services konfiguriert werden können. Zusätzlich soll es über die Oberfläche auch möglich sein, Benutzer und Rollen hinzuzufügen, zu löschen und zu ändern. Diese und weitere Anwendungsfälle der Benutzerverwaltung werden im Folgenden spezifiziert. Zum besseren Verständnis kann die finale Ansicht der Benutzerverwaltung in Abbildung A2 hinzugezogen werden. Anwendungsfall 3: Identity Service hinzufügen Vorbedingung: Es werden die Sicherheitseinstellungen eines Prozesses angezeigt. Regulärer Ablauf: 1. Der Akteur klickt auf die Schaltfläche Add Identity Service. 2. Es öffnet sich ein Dialog, in dem der Akteur den Typ des Identity Services, den Namen des Realms und weitere Eigenschaften angibt, die zur Erzeugung des Identity Services benötigt werden. 3. Der Akteur klickt im Dialog auf die Schaltfläche OK. Nachbedingung: Die Ansicht ist aktualisiert und zeigt den hinzugefügten Identity Service an. Alle Benutzer, die der Identity Service zur Verfügung stellt, können sich bei abgesicherten Endpunkten/Operationen des Prozesses authentifizieren. Alternative Abläufe: Zu 3. Der Akteur klickt im Dialog auf die Schaltfläche Abbrechen. Es wird kein Identity Service zu dem Prozess hinzugefügt. Zu 3. Die spezifizierten Einstellungen zur Erzeugung des Identity Services sind ungültig oder unvollständig. Es wird eine entsprechende Fehlermeldung angezeigt. Anwendungsfall 4: Identity Service entfernen Vorbedingung: Es werden die Sicherheitseinstellungen eines Prozesses angezeigt. Der Prozess verfügt über einen Identity Service. 77

88 Kapitel 4: Konzept & Spezifikation Regulärer Ablauf: 1. Der Akteur klickt in dem Bereich, in dem der entsprechende Identity Service angezeigt wird, auf die Schaltfläche Remove. Es öffnet sich ein Dialog, in dem der Akteur das Entfernen des Identity Services bestätigen muss. 2. Der Akteur klickt im Dialog auf die Schaltfläche OK. Nachbedingung: Die Ansicht ist aktualisiert und zeigt den entfernten Identity Service nicht mehr an. Alle Benutzer, die der Identity Service zur Verfügung stellt, können sich bei abgesicherten Endpunkten/Operationen des Prozesses nicht mehr authentifizieren. Alternative Abläufe: Zu 2. Der Akteur klickt im Dialog auf die Schaltfläche Cancel. Der Identity Service wird nicht entfernt. Anwendungsfall 5: Benutzer zu Identity Service hinzufügen Vorbedingung: Es werden die Sicherheitseinstellungen eines Prozesses angezeigt. Der Prozess verfügt über einen Identity Service. Regulärer Ablauf: 1. Der Akteur klickt in dem Bereich, in dem der entsprechende Identity Service angezeigt wird, auf die Schaltfläche Add User. Es öffnet sich ein Dialog, in dem der Akteur den Namen des Benutzer eingeben muss. 2. Der Akteur klickt im Dialog auf die Schaltfläche OK. Es öffnet sich ein Dialog, in dem der Akteur das Passwort des Benutzer eingeben muss. 3. Der Akteur klickt im Dialog auf die Schaltfläche OK. Nachbedingung: Die Ansicht ist aktualisiert und zeigt den hinzugefügten Benutzer an. Der Benutzer kann sich bei entsprechend abgesicherten Endpunkten/Operationen des Prozesses mit seinem Benutzernamen und Passwort authentifizieren. Zudem kann in BPEL über die in 4.3 definierten Erweiterungen auf Eigenschaften und Rollen des Benutzers zugegriffen werden. Alternative Abläufe: Zu Der Akteur klickt im Dialog auf die Schaltfläche Cancel. Es wird kein Benutzer zu dem Identity Service hinzugefügt. Zu Existiert der angegebene Benutzer bereits oder ist der eingegebene Name oder das eingegeben Password ungültig, wird eine entsprechende Fehlermeldung angezeigt. Anwendungsfall 6: Benutzer von Identity Service entfernen Vorbedingung: Es werden die Sicherheitseinstellungen eines Prozesses angezeigt. Der Prozess verfügt über einen Identity Service mit mindestens einem Benutzer. 78

89 Kapitel 4: Konzept & Spezifikation Regulärer Ablauf: 1. Der Akteur klickt in dem Bereich, in dem der zu entfernende Benutzer angezeigt wird, auf die Schaltfläche -. Es öffnet sich ein Dialog, in dem der Akteur das Entfernen des Benutzers bestätigen muss. 2. Der Akteur klickt im Dialog auf die Schaltfläche OK. Nachbedingung: Die Ansicht ist aktualisiert und zeigt den entfernten Benutzer nicht mehr an. Der Benutzer kann sich bei abgesicherten Endpunkten/Operationen des Prozesses nicht mehr authentifizieren. Alternative Abläufe: Zu 2. Der Akteur klickt im Dialog auf die Schaltfläche Cancel. Der Benutzer wird nicht entfernt. Anwendungsfall 7: Benutzerpasswort ändern Vorbedingung: Es werden die Sicherheitseinstellungen eines Prozesses angezeigt. Der Prozess verfügt über einen Identity Service mit mindestens einem Benutzer. Regulärer Ablauf: 1. Der Akteur klickt in dem Bereich, in dem der entsprechende Benutzer angezeigt wird, auf die Schaltfläche. Es öffnet sich ein Dialog, in dem der Akteur das bisherige Passwort des Benutzers eingeben muss. 2. Der Akteur klickt im Dialog auf die Schaltfläche OK. Es öffnet sich ein Dialog, in dem der Akteur das neue Passwort des Benutzers eingeben muss. Nachbedingung: Das Passwort des Benutzers ist geändert. Der Benutzer kann sich mit dem neuen Passwort beim Prozess authentifizieren Alternative Abläufe: Zu Der Akteur klickt im Dialog auf die Schaltfläche Cancel. Der Benutzer wird nicht entfernt. Zu 3. Kann das Passwort nicht geändert werden (z.b. weil eines der Passwörter ungültig ist), wird eine entsprechende Fehlermeldung angezeigt. Anwendungsfall 8: Rolle zu Identity Service hinzufügen Vorbedingung: Es werden die Sicherheitseinstellungen eines Prozesses angezeigt. Der Prozess verfügt über einen Identity Service. Regulärer Ablauf: 1. Der Akteur klickt in dem Bereich, in dem der entsprechende Identity Service angezeigt wird, auf die Schaltfläche Add Role. Es öffnet sich ein Dialog, in dem der Akteur den Namen der Rolle eingeben muss. 2. Der Akteur klickt im Dialog auf die Schaltfläche OK. 79

90 Kapitel 4: Konzept & Spezifikation Nachbedingung: Die Ansicht ist aktualisiert und zeigt die hinzugefügte Rolle an. Alternative Abläufe: Zu 2. Der Akteur klickt im Dialog auf die Schaltfläche Cancel. Es wird keine Rolle zu dem Identity Service hinzugefügt. Zu 2. Existiert die angegebene Rolle bereits oder ist der eingegebene Name ungültig, wird eine entsprechende Fehlermeldung angezeigt. Anwendungsfall 9: Rolle von Identity Service entfernen Vorbedingung: Es werden die Sicherheitseinstellungen eines Prozesses angezeigt. Der Prozess verfügt über einen Identity Service mit mindestens einer Rolle. Regulärer Ablauf: 1. Der Akteur klickt in dem Bereich, in dem die zu entfernende Rolle angezeigt wird, auf die Schaltfläche -. Es öffnet sich ein Dialog, in dem der Akteur das Entfernen der Rolle bestätigen muss. 2. Der Akteur klickt im Dialog auf die Schaltfläche OK. Nachbedingung: Die Ansicht ist aktualisiert und zeigt die entfernte Rolle nicht mehr an. Alternative Abläufe: Zu 2. Der Akteur klickt im Dialog auf die Schaltfläche Cancel. Die Rolle wird nicht entfernt. Anwendungsfall 10: Benutzer Rolle zuweisen Vorbedingung: Es werden die Sicherheitseinstellungen eines Prozesses angezeigt. Der Prozess verfügt über einen Identity Service mit mindestens einem Benutzer und mindestens einer Rolle. Regulärer Ablauf: 1. Der Akteur klickt in dem Bereich, in dem die Rollen des Benutzers angezeigt werden, auf die Schaltfläche Es öffnet sich ein Dialog, in dem der Akteur den Namen der zuzuweisenden Rolle angibt. 3. Der Akteur klickt im Dialog auf die Schaltfläche OK. Nachbedingung: Die Ansicht ist aktualisiert und zeigt die zugewiesene Rolle als Rolle des Benutzers an. Alternative Abläufe: Zu 3. Der Akteur klickt im Dialog auf die Schaltfläche Cancel. Die Rolle wird nicht zugewiesen. 80

91 Kapitel 4: Konzept & Spezifikation Zu 3. Existiert die angegebene Rolle nicht, wird eine entsprechende Fehlermeldung angezeigt. Anwendungsfall 11: Benutzer Rolle entziehen Vorbedingung: Es werden die Sicherheitseinstellungen eines Prozesses angezeigt. Der Prozess verfügt über einen Identity Service mit mindestens einem Benutzer und mindestens einer Rolle. Regulärer Ablauf: 1. Der Akteur klickt in dem Bereich, in dem die Rollen des Benutzers angezeigt werden, auf die Schaltfläche Es öffnet sich ein Dialog, in dem der Akteur den Namen der zu entziehenden Rolle angibt. 3. Der Akteur klickt im Dialog auf die Schaltfläche OK. Nachbedingung: Die Ansicht ist aktualisiert und zeigt die entzogene Rolle nicht mehr als Rolle des Benutzers an. Alternative Abläufe: Zu 3. Der Akteur klickt im Dialog auf die Schaltfläche Cancel. Die Rolle wird nicht entzogen. Zu 3. Existiert die angegebene Rolle nicht, wird eine entsprechende Fehlermeldung angezeigt. Anwendungsfall 12: Eigenschaft zu Benutzer hinzufügen Vorbedingung: Es werden die Sicherheitseinstellungen eines Prozesses angezeigt. Der Prozess verfügt über einen Identity Service mit mindestens einem Benutzer. Regulärer Ablauf: 1. Der Akteur klickt in dem Bereich, in dem die Eigenschaften des Benutzers angezeigt werden, auf die Schaltfläche Es öffnet sich ein Dialog, in dem der Akteur den Namen und den Wert der hinzuzufügenden Eigenschaft angibt. 3. Der Akteur klickt im Dialog auf die Schaltfläche OK. Nachbedingung: Die Ansicht ist aktualisiert und zeigt die hinzugefügte Eigenschaft als Eigenschaft des Benutzers an. Auf den Wert der Eigenschaft kann in BPEL über die XPath-Funktion getuserproperty zugegriffen werden. Zudem kann die Eigenschaft als Platzhalter in der Endpunktkonfiguration verwendet werden (siehe 4.2.8). Alternative Abläufe: Zu 3. Der Akteur klickt im Dialog auf die Schaltfläche Cancel. Die Eigenschaft wird nicht hinzugefügt. 81

92 Kapitel 4: Konzept & Spezifikation Anwendungsfall 13: Eigenschaft von Benutzer entfernen Vorbedingung: Es werden die Sicherheitseinstellungen eines Prozesses angezeigt. Der Prozess verfügt über einen Identity Service mit mindestens einem Benutzer. Regulärer Ablauf: 1. Der Akteur klickt in dem Bereich, in dem die Eigenschaften des Benutzers angezeigt werden, auf die Schaltfläche Es öffnet sich ein Dialog, in dem der Akteur den Namen der zu entfernenden Eigenschaft angibt. 3. Der Akteur klickt im Dialog auf die Schaltfläche OK. Nachbedingung: Die Ansicht ist aktualisiert und zeigt die entfernte Eigenschaft nicht mehr als Eigenschaft des Benutzers an. Alternative Abläufe: Zu 3. Der Akteur klickt im Dialog auf die Schaltfläche Cancel. Die Eigenschaft wird nicht entfernt. Zu 3. Existiert die angegebene Eigenschaft nicht, wird eine entsprechende Fehlermeldung angezeigt Anwendungsfälle der Zugriffsrechteverwaltung In der Zugriffsrechteverwaltung können Zugriffsrechte auf Ressourcen vergeben werden. Eine Ressource wird dabei über einen eindeutigen Bezeichner, wie z.b. den Namen eines Endpunktes oder einer Operation identifiziert. Zu jeder Ressource können diejenigen Rollen und Benutzer angegeben werden, denen ein Zugriff auf die Ressource erlaubt ist. Die folgenden Anwendungsfälle wurden in der Ansicht aus Abbildung A3 realisiert. Anwendungsfall 14: Zugriffskontrolle für Ressource aktivieren Vorbedingung: Es werden die Sicherheitseinstellungen eines Prozesses angezeigt. Regulärer Ablauf: 1. Der Akteur wählt in der Auswahlliste im Bereich Authorization den Namen der Ressource aus, für die die Zugriffskontrolle aktiviert werden soll. 2. Der Akteur klickt auf die Schaltfläche Add Authorization Target. Nachbedingung: Die Ansicht ist aktualisiert und zeigt den Namen der Ressource sowie die Zugriffsberechtigungen für die Ressource in der Tabelle der geschützten Ressourcen an. Die Zugriffsberechtigungen für die Ressource sind leer. Falls die Sicherheit des Prozesses global aktiviert ist, wird eine Zugriffskontrolle für die angegebene Ressource durchgeführt. 82

93 Kapitel 4: Konzept & Spezifikation Alternative Abläufe: Zu 2. Ist in der Auswahlliste der Eintrag <Custom> ausgewählt, öffnet sich ein Dialog, in dem der Akteur den Namen der zu schützenden Ressource manuell eingeben kann. Klickt der Akteur in dem Dialog auf OK, gilt die Nachbedingung. Klickt er auf Cancel, wird der Vorgang abgebrochen. Anwendungsfall 15: Zugriffskontrolle für Ressource deaktivieren Vorbedingung: Es werden die Sicherheitseinstellungen eines Prozesses angezeigt. Der Prozess verfügt über mindestens eine geschützte Ressource. Regulärer Ablauf: 1. Der Akteur klickt in dem Bereich, in dem der Name der geschützten Ressource angezeigt werden, auf die Schaltfläche -. Es öffnet sich ein Dialog, in dem der Akteur das Deaktivieren der Zugriffskontrolle bestätigen muss. 2. Der Akteur klickt auf die Schaltfläche OK. Nachbedingung: Die Ansicht ist aktualisiert und zeigt den Namen der ausgewählten Ressource nicht mehr in der Tabelle der zu schützenden Ressourcen an. Die Zugriffskontrolle für die ausgewählte Ressource ist deaktiviert. Alternative Abläufe: Zu 3. Der Akteur klickt im Dialog auf die Schaltfläche Cancel. Die Zugriffskontrolle für die Ressource bleibt aktiviert. Anwendungsfall 16: Zugriffsberechtigung für Ressource vergeben Vorbedingung: Es werden die Sicherheitseinstellungen eines Prozesses angezeigt. Der Prozess verfügt über mindestens eine geschützte Ressource. Regulärer Ablauf: 1. Der Akteur klickt in dem Bereich, in dem die berechtigten Benutzer/Rollen der geschützten Ressource angezeigt werden, auf die Schaltfläche Es öffnet sich ein Dialog, in dem der Akteur den Namen der organisatorischen Einheit (Benutzer/Rolle) angibt, die zum Zugriff auf die Ressource berechtigt werden soll. 3. Der Akteur klickt auf die Schaltfläche OK. Nachbedingung: Die Ansicht ist aktualisiert und zeigt den Namen der ausgewählten organisatorischen Einheit in der Liste der berechtigten organisatorischen Einheiten der Ressource an. Wurde ein Benutzer angeben, erhält dieser Zugriff auf die Ressource. Wurde eine Rolle angegeben, erhalten alle Benutzer, denen diese Rolle zugewiesen ist, Zugriff auf die Ressource. 83

94 Kapitel 4: Konzept & Spezifikation Alternative Abläufe: Zu 3. Der Akteur klickt im Dialog auf die Schaltfläche Cancel. Es wird keine Zugriffsberechtigung vergeben. Anwendungsfall 17: Zugriffsberechtigung für Ressource entziehen Vorbedingung: Es werden die Sicherheitseinstellungen eines Prozesses angezeigt. Der Prozess verfügt über mindestens eine geschützte Ressource mit mindestens einer berechtigten organisatorischen Einheit (Benutzer/Rolle). Regulärer Ablauf: 1. Der Akteur klickt in dem Bereich, in dem die berechtigten Benutzer/Rollen der geschützten Ressource angezeigt werden, auf die Schaltfläche Es öffnet sich ein Dialog, in dem der Akteur den Namen der organisatorischen Einheit (Benutzer/Rolle) angibt, der der Zugriff auf die Ressource entzogen werden soll. 3. Der Akteur klickt auf die Schaltfläche OK. Nachbedingung: Die Ansicht ist aktualisiert und zeigt den Namen der ausgewählten organisatorischen Einheit nicht mehr in der Liste der berechtigten organisatorischen Einheiten der Ressource an. Alternative Abläufe: Zu 3. Der Akteur klickt im Dialog auf die Schaltfläche Cancel. Es wird keine Zugriffsberechtigung entzogen Anwendungsfälle der Endpunkteverwaltung Über die Endpunkteverwaltung wird die Sicherheit von Endpunkten und deren Operationen konfiguriert. Jedem Endpunkt und jeder Operation können Credentials zugewiesen werden, die beim Austausch von Nachrichten über den Endpunkt/die Operation verwendet werden. Dazu gehören neben Benutzernamen und Passwort auch die privaten Schlüssel und Zertifikate, mit denen eine Verschlüsselung, Entschlüsselung und Signatur der Nachrichten durchgeführt wird (siehe 4.2.8). Die Schlüssel werden nicht direkt angegeben, sondern über Keystores referenziert, die ebenfalls konfiguriert werden müssen. Entsprechend ergeben sich für die Endpunkteverwaltung die in diesem Kapitel aufgelisteten Anwendungsfälle. Die verschiedenen Ansichten der Endpunkteverwaltung werden in den Abbildungen A4 A7 gezeigt. Anwendungsfall 18: Sicherheitseinstellungen eines Endpunkt/einer Operation erstellen Vorbedingung: Es werden die Sicherheitseinstellungen eines Prozesses angezeigt. Im Bereich Endpoint Settings ist das Tab Inbound oder das Tab Outbound geöffnet. 84

95 Kapitel 4: Konzept & Spezifikation Regulärer Ablauf: 1. Der Akteur wählt in der Auswahlliste die Entität (Endpunkt/Operation) aus, für die Sicherheitseinstellungen erstellt werden sollen. 2. Der Akteur klickt auf die Schaltfläche Add Settings. Nachbedingung: Die Ansicht ist aktualisiert und zeigt in der Liste der Einstellungen den Namen der ausgewählten Entität an. Falls die Sicherheit des Prozesses global aktiviert ist, werden die Sicherheitseinstellungen für die Entität aktiviert. Alternative Abläufe: Zu 2. Ist in der Auswahlliste der Eintrag <Custom> ausgewählt, öffnet sich ein Dialog, in dem der Akteur den Namen der Entität manuell eingeben kann. Klickt der Akteur in dem Dialog auf OK, gilt die Nachbedingung. Klickt er auf Cancel, wird der Vorgang abgebrochen. Anwendungsfall 19: Sicherheitseinstellungen eines Endpunkts/einer Operation löschen Vorbedingung: Es werden die Sicherheitseinstellungen eines Prozesses angezeigt. Im Bereich Endpoint Settings ist das Tab Inbound oder das Tab Outbound geöffnet. Es existieren Sicherheitseinstellungen für mindestens eine Entität (Endpunkt/ Operation). Regulärer Ablauf: 1. Der Akteur wählt in der Auswahlliste die Entität aus, deren Sicherheitseinstellungen entfernt werden sollen. 2. Der Akteur klickt auf die Schaltfläche Remove Settings. Es öffnet sich ein Dialog, in dem der Akteur das Entfernen der Sicherheitseinstellungen bestätigen muss. 3. Der Akteur klickt auf die Schaltfläche OK. Nachbedingung: Die Ansicht ist aktualisiert und zeigt in der Liste der Sicherheitseinstellungen den Namen der ausgewählten Entität nicht mehr an. Die Sicherheitseinstellungen für die Entität sind deaktiviert. Alternative Abläufe: Zu 3. Der Akteur klickt im Dialog auf die Schaltfläche Cancel. Die Sicherheitseinstellungen werden nicht gelöscht. Anwendungsfall 20: Sicherheitseinstellungen eines Endpunkts/einer Operation ändern Vorbedingung: Es werden die Sicherheitseinstellungen eines Prozesses angezeigt. Im Bereich Endpoint Settings ist das Tab Inbound oder das Tab Outbound geöffnet. Es existieren Sicherheitseinstellungen für mindestens eine Entität (Endpunkt/ Operation). 85

96 Kapitel 4: Konzept & Spezifikation Regulärer Ablauf: 1. Der Akteur wählt in der Auswahlliste die Entität aus, deren Sicherheitseinstellungen geändert werden sollen. 2. Der Akteur ändert die Sicherheitseinstellungen. 3. Der Akteur klickt auf die Schaltfläche Save. Nachbedingung: Der Entität sind die geänderten Sicherheitseinstellungen zugewiesen. Der Entität wird entsprechend aktualisiert. Alternative Abläufe: Zu 3. Der Akteur wechselt die ausgewählten Sicherheitseinstellungen. Die vorgenommenen Änderungen gehen verloren. Anwendungsfall 21: Credentials/Keystore-Einstellungen erstellen Vorbedingung: Es werden die Sicherheitseinstellungen eines Prozesses angezeigt. Im Bereich Endpoint Settings ist das Tab Credentials / Keystores geöffnet. Regulärer Ablauf: 1. Der Akteur klickt auf die Schaltfläche Add Credentials / Add Keystore. 2. Es öffnet sich ein Dialog, in dem der Akteur den Namen der zu erstellenden Credentials/Keystore-Einstellungen angibt. 3. Der Akteur klickt im Dialog auf die Schaltfläche OK. Nachbedingung: Die Ansicht ist aktualisiert und zeigt in der Liste aller Credentials/ Keystore-Einstellungen den Namen der erstellten Credentials/Keystore-Einstellungen an. Alternative Abläufe: Zu 3. Der Akteur klickt im Dialog auf die Schaltfläche Cancel. Der Vorgang wird abgebrochen. Anwendungsfall 22: Credentials/Keystore-Einstellungen löschen Vorbedingung: Es werden die Sicherheitseinstellungen eines Prozesses angezeigt. Im Bereich Endpoint Settings ist das Tab Credentials / Keystores geöffnet. Es existieren Credentials/Keystore-Einstellungen. Regulärer Ablauf: 1. Der Akteur wählt in der Auswahlliste den Namen der Credentials/KeystoreEinstellungen aus, die entfernt werden sollen. 2. Der Akteur klickt auf die Schaltfläche Remove Credentials / Remove Keystore. Es öffnet sich ein Dialog, in dem der Akteur das Entfernen der Credentials/Keystore-Einstellungen bestätigen muss. 3. Der Akteur klickt im Dialog auf die Schaltfläche OK. 86

97 Kapitel 4: Konzept & Spezifikation Nachbedingung: Die Ansicht ist aktualisiert und zeigt in der Liste aller Credentials/ Keystore-Einstellungen die gelöschten Credentials/Keystore-Einstellungen nicht mehr an. Alternative Abläufe: Zu 3. Der Akteur klickt im Dialog auf die Schaltfläche Cancel. Der Vorgang wird abgebrochen. Anwendungsfall 23: Credentials/Keystore-Einstellungen ändern Vorbedingung: Es werden die Sicherheitseinstellungen eines Prozesses angezeigt. Im Bereich Endpoint Settings ist das Tab Credentials / Keystores geöffnet. Es existieren Credentials/Keystore-Einstellungen. Regulärer Ablauf: 1. Der Akteur wählt in der Liste die zu ändernden Credentials/Keystore-Einstellungen aus. 2. Der Akteur ändert die Eigenschaften der Credentials/Keystore-Einstellungen. 3. Der Akteur klickt auf die Schaltfläche Save. Nachbedingung: Alle Endpunkte/Operationen, die die geänderten Credentials/Keystore-Einstellungen verwenden, sind aktualisiert. Alternative Abläufe: Zu 3. Der Akteur wechselt die ausgewählten Credentials/Keystore-Einstellungen. Die vorgenommenen Änderungen gehen verloren. 87

98

99 Kapitel 5: Entwurf & Implementierung Kapitel 5 Entwurf & Implementierung Im vorherigen Kapitel wurden die Sicherheitsanforderungen an die BPEL Engine Apache ODE spezifiziert. Des Weiteren wurden grundlegende Konzepte sowie Spracherweiterungen für die Umsetzung der Anforderungen entwickelt. Dieses Kapitel befasst sich nun mit dem Entwurf und der Implementierung der Konzepte und Erweiterungen. Es werden zunächst die Technologien beschrieben, die im praktischen Teil dieser Diplomarbeit eingesetzt wurden. Die Apache ODE (ODE) und im Speziellen deren Architektur wird hierbei separat in Kapitel 5.2 betrachtet. Um eine kontextbezogene Sicherheit zu ermöglichen, wurde die Engine um eine Sicherheitskomponente erweitert. Kapitel 5.3 beschreibt deren Entwurf und Implementierung. Die Integration der Komponente bildete den zweiten Aufgabenteil. Im Zuge der Integration sowie der Implementierung der Spracherweiterungen mussten an verschiedenen Stellen Änderungen an der ODE vorgenommen werden. Diese Änderungen werden in 5.4 erläutert. 5.1 Verwendete Technologien Für die Implementierung wurde auf bestehende Frameworks und Bibliotheken zurückgegriffen. Diese sind Teil verschiedener Open Source Projekte der Apache Software Foundation38 und basieren allesamt auf der Java-Technologie von Sun Microsystems39. Kenntnisse der Programmiersprache Java sowie weiterer Komponenten der Java Technologie, wie z.b. Servlets und Servlet-Containern [SUN03], werden im folgenden vorausgesetzt. Im Rahmen der Diplomarbeit wurde Java (Java 5 Update 16) verwendet, da einige der verwendeten Bibliotheken noch nicht kompatibel zur aktuellen Version waren. Alle Erweiterungen der ODE sowie die Entwicklung der Sicherheitskomponenten wurden mit der Entwicklungsumgebung Eclipse40 (Version 3.3.2) vorgenommen. Als Lauf38 ( ) ( ) 40 ( ) 39 89

100 Kapitel 5: Entwurf & Implementierung zeitumgebung für ODE kam die aktuelle Version des Web Servers und ServletContainers Apache Tomcat41 zum Einsatz Apache Axis2 Apache Axis2 (Axis2) ist eine Bibliothek, die das vom W3C definierte SOAP-Protokoll implementiert und als Web Service Engine eingesetzt werden kann. Dabei können sowohl Web Services bereitgestellt als auch aufgerufen werden. Zur Bereitstellung von Web Services kann Axis2 entweder Standalone oder als Servlet innerhalb eines ServletContainers (z.b. Apache Tomcat) ausgeführt werden [AXIS]. Die Verwendung von Web Services erfolgt bei Axis2 über ein Objektmodell, welches im Wesentlichen die Struktur der WSDL nachbildet. Lädt man über die Funktionen der Bibliothek beispielsweise eine WSDL-Datei, wird aus einem darin definierten <service> Element ein Objekt des Typs AxisService erzeugt. Das Objekt verweist dabei auf weitere Objekte des Typs AxisEndpoint und AxisOperation, die Endpunkte (<endpoint>) bzw. Operationen (<operation>) des Web Services repräsentieren. Policies, die innerhalb der WSDL-Datei enthalten sind oder referenziert werden, lädt Axis2 mit Hilfe des WS-Policy Frameworks Apache Neethi (siehe 5.1.3). Die Policies werden dabei ebenfalls in ein Objektmodell umgewandelt und von den jeweiligen WSDL Objekten referenziert. Zum Aufruf von Web Services stellt Axis2 die Klasse ServiceClient zur Verfügung. Ein ServiceClient referenziert ein AxisService Objekt und kann dessen Operationen aufrufen. Über ein Options Objekt ist es dabei möglich, Angaben innerhalb des AxisService Objekts, wie z.b. Endpunktadressen, zu überschreiben oder zusätzliche Eigenschaften, wie z.b. die SOAP Action der Operation oder die zu verwendende Security Policy, anzugeben. Die Methoden sendreceive und sendreceivenonblocking ermöglichen einen blockierenden bzw. nicht-blockierenden Aufruf des Web Services. Alternativ kann mit der Methode createclient zunächst ein OperationClient erzeugt werden. Ein OperationClient kapselt die Aufrufe einer einzelnen Operation und führt diese über die Methode execute aus. Zusätzlich unterstützten OperationClients die Ausführung komplexer Message Exchange Patterns (siehe [SOAP07]). Für die Verarbeitung von XML verwendet Axis2 ein eigens entwickeltes Objektmodell namens AXIOM (Axis Object Model), welches auf dem in [BEA03] spezifizierten Pull-Parsing Mechanismus basiert. Im Vergleich zu anderen Dokumentmodellen (DOM, JDOM,...) soll AXIOM sich durch eine hohe Entwicklerfreundlichkeit sowie eine höhere Performanz auszeichnen. Die Funktionalität von Axis2 kann über sog. Module erweitert werden. Ein Modul kann sich an einer beliebigen Stelle in den Nachrichtenverarbeitungsprozess der Engine einklinken und Änderungen an den ein- und ausgehenden Nachrichten vornehmen. Dazu kann es auf Policies innerhalb des Objektmodells zugreifen. Dies ermöglicht es, die Engine nachträglich um beliebige WS-* Standards zu erweitern. Zurzeit existieren ( ) ( ) 90

101 Kapitel 5: Entwurf & Implementierung Module, die die Standards WS-ReliableMessaging, WS-Coordination und WS-Security (siehe 5.1.2) implementieren. WS-Addressing wird bereits nativ von Axis2 unterstützt. Im Rahmen dieser Arbeit wurde die Version 1.4 von Axis verwendet Apache Rampart Apache Rampart (Rampart) ist ein Modul für Axis2, das die Web Service Engine um die Standards WSS, WS-SecurityPolicy, WS-SecureConversation und WS-Trust erweitert. WS-SecureConversation WS-SecurityPolicy und WS-Trust werden dabei von Rampart selbst implementiert. Für WSS verwendet Rampart intern die Bibliothek Apache WSS4J43 [RAMP]. Da Rampart WS-SecurityPolicy unterstützt, können die Sicherheitseinstellungen eines Web Services über eine Security Policy konfiguriert werden (siehe ). Wird eine Nachricht gesendet oder empfangen, führt Rampart an den entsprechenden Stellen des Nachrichtenverarbeitungsprozesses Aktionen durch, die aus der Policy abgeleitet werden können. Dazu gehört beispielsweise die Verschlüsselung und Entschlüsselung von Nachrichten sowie die Überprüfung von Signaturen und Benutzername/Passwort Angaben. Um dies durchzuführen, müssen Rampart Informationen über die zu verwendenden Credentials gegeben werden. Dies geschieht über domänenspezifische Policy Assertion, die innerhalb der Security Policy platziert werden müssen. Dabei können nur nicht-geheime Credentials (Benutzername, Keystore Alias,...) direkt angegeben werden. Passwörter, die für den Versand oder die Entschlüsselung von Nachrichten benötigt werden, fordert Rampart über einen Callback Mechanismus zur Laufzeit an. In der Policy Assertion muss dazu der Name einer Java-Klasse angegeben werden, deren Instanzen als Callback Handler dienen. Die aktuelle Version von Apache Rampart ist Version 1.4. Diese Version wurde auch im praktischen Teil dieser Arbeit verwendet Apache Neethi Apache Neethi (Neethi) stellt ein Framework zur Verarbeitung von Policies bereit. Dazu implementiert es ein Objektmodell von WS-Policy. Zudem können Policy Assertions mit in das Objektmodell integriert werden. Dazu muss eine Klasse die Schnittstelle Assertion implementieren und Neethi über die Metadaten eines Java Archives (JAR) bekannt gemacht werden [NEE]. Im Rahmen der Diplomarbeit wurde Neethi eingesetzt, um Policies zu laden, anzupassen und damit die von Axis2 bereitgestellten Dienste zu konfigurieren. 5.2 Orchestration Director Engine Die Orchestration Director Engine (ODE) ist eine Open Source BPEL Engine, die, ebenso wie Axis2, Rampart und Neethi unter der Schirmherrschaft der Apache Software 43 ( ) 91

102 Kapitel 5: Entwurf & Implementierung Foundation44 entwickelt wird. Das aktuelle Release (Version 1.2) stammt vom 3. Juli Die Änderungen der Diplomarbeit wurden jedoch auf der Entwicklerversion vom 19. November 2008 (Revision ) durchgeführt. ODE unterstützt sowohl den alten BPEL Standard 1.1. als auch die aktuelle Version 2.0. Beide Standards können in Kombination mit XPath 1.0 und 2.0 eingesetzt werden. Zudem soll mit dem nächsten Release die Sprache XQuery45 unterstützt werden. Zur Kommunikation mit der Außenwelt greift ODE auf die Funktionen einer Kommunikationsschicht zurück. Diese ist gleichzusetzen mit der Middleware aus Kapitel 3. Aktuell kann als Middleware entweder Axis2 oder ein auf dem Standard Java Business Integration (JBI) [TeW05] basierender ESB verwendet werden [ODE]. Um die später beschriebenen Erweiterungen besser verstehen und einordnen zu können, werden der Aufbau von ODE und die Funktionsweise der einzelnen Komponenten nun genauer betrachtet. Abbildung 5.1 liefert hierzu zunächst einen Überblick über die Systemarchitektur. Im folgenden wird beschrieben, worin die Aufgaben der einzelnen Komponenten liegen und wie diese zusammenarbeiten. Abbildung 5.1: Architektur der Apache ODE ( ) ( ) 92

103 Kapitel 5: Entwurf & Implementierung Deployment Unit & BPEL Compiler Eine Deployment Unit ist eine Kollektion von Dateien, die ein oder mehrere Prozesse beschreiben. Neben BPEL Dateien gehören dazu beispielsweise WSDL Dateien, in denen die Schnittstellen und Partnerlinks der Prozesse beschrieben sind. Jede Deployment Unit muss zudem über einen Deployment Descriptor (deploy.xml) verfügen, in dem unter anderem die Bindings der Endpunkte festgelegt werden. Der BPEL Compiler kompiliert diese Dateien zu einem Prozessmodell, welches von der BPEL Runtime ausgeführt werden kann. Da es sich bei dem Prozessmodell um eine Struktur aus Java Objekten handelt, wird es als OModel bezeichnet. Um wiederholte Kompilierungen bei Neustarts der Engine zu vermeiden, wird das OModel einer Deployment Unit serialisiert und in einer CBP (Compiled Business Process) Datei gespeichert Integration Layer Zur Kommunikation mit der Außenwelt greift die BPEL Runtime auf Funktionen der zugrunde liegenden Middleware zurück. Zu diesen Funktionen gehören beispielsweise die Bereitstellung oder der Aufruf von Endpunkten. Der Zugriff auf die Middleware erfolgt dabei über einheitliche Schnittstellen, die von sog. Integration Layers (in Abbildung 5.1: Axis2, JBI, SCA,...) implementiert werden. Ein Integration Layer fungiert unter anderem als Adapter zwischen der BPEL Runtime und der Middleware: Eingehende Nachrichten werden abgefangen, in eine einheitliche Struktur konvertiert und an die BPEL Engine weitergegeben. Bei ausgehenden Nachrichten findet entsprechend eine umgekehrte Konvertierung statt. Zudem ist der Integration Layer ebenfalls dafür verantwortlich die BPEL Engine zu starten und Web Services bereitzustellen, über die eine Verwaltung der Prozesse und Prozessinstanzen möglich ist. Für ODE wurden bisher Integration Layers zu Axis2 und JBI implementiert. Ein weiterer Integration Layer, durch den ODE in eine Java-basierte Service Component Architecture (SCA) eingebettet werden kann, befindet sich zur Zeit in der Entwicklung. Im Rahmen der Diplomarbeit wurde die Kommunikation über den Axis2 Integration Layer abgesichert. Um ein besseres Verständnis für die später beschriebenen Änderungen zu ermöglichen, wird das Zusammenspiel zwischen Axis2 Engine, Integration Layer und BPEL Engine nachfolgend erklärt. Der Axis2 Integration Layer instantiiert die BPEL Runtime innerhalb eines Servlets der Klasse ODEAxisServlet. Dabei weist sie der Runtime einen BindingContext zu, über den die Runtime auf Funktionen des Integration Layers zugreifen kann. Die Methode activatemyroleendpoint wird beispielsweise zur Aktivierung von Endpunkten verwendet. Ruft die Runtime diese Funktion auf, verwendet der Integration Layer die Klassen von Axis2, um den Endpunkt bereitzustellen: Ein Factory-Objekt der Klasse WSDL11ServiceBuilder erzeugt aus der angegebenen WSDL Definition das Objektmodell des Web Services (siehe 5.1.1). Bei allen Operationen des Web Services wird ein MessageReceiver vom Typ ODEMessageReceiver registriert. Sobald eine SOAP-Nachricht an das Servlet gesendet wird, ermittelt die Axis Engine die Zieloperation, verarbeitet die Nachricht entsprechend und ruft anschließend die Funktion invokebusinesslogic des ODEMessageReceivers auf. Der Funktion wird dabei ein Objekt der Klasse MessageContext 93

104 Kapitel 5: Entwurf & Implementierung als Parameter übergeben. Über das Objekt können, neben der SOAP-Nachricht selbst, weitere Informationen abgerufen werden, die während des Verarbeitungsprozesses mit der Nachricht assoziiert wurden (HTTP-Header, Session-IDs, Benutzerinformationen, etc.). Der Integration Layer beschränkt sich jedoch darauf, die Nachricht von dem Axis eigenen XML Objektmodell (AXIOM) in das DOM zu konvertieren und über ein Objekt vom Typ MyRoleMessageExchange an die Runtime Komponente der BPEL Engine weiterzureichen. Dort wird in einem parallelen Thread die zuständige Prozessinstanz ermittelt und ausgeführt. Der Thread des Servlet-Aufrufs wird so lange pausiert bis die Methode onasyncack des MyRoleMessageExchange Objekts aufgerufen wird. Dies geschieht, sobald die dem Aufruf zugeordnete reply Aktivität ausgeführt wird. Der Methode wird dabei über einen Parameter die Antwortnachricht der Operation übergeben. Der Integration Layer sorgt mit einem Aufruf der Axis Engine schließlich dafür, dass die Nachricht als Antwort des Servlet-Aufrufs zurückgegeben wird. Den Ausgangspunkt für den Aufruf von Web Services durch die Runtime Komponente bildet die Methode createpartnerrolechannel der Schnittstelle BindingContext. Die Implementierung dieser Methode erzeugt ein Objekt vom Typ PartnerRoleChannel, welches einen Kanal zu dem angegeben Partner repräsentiert. Zum Aufruf einer Operation des Partners instantiiert die Runtime Komponente ein Objekt vom Typ PartnerRoleMessageExchange. Dieses kapselt alle Informationen, die von dem Integration Layer für den Web Service Aufruf benötigt werden. dazu gehören unter anderem: Die zu sendende Nachrichten Den PartnerRoleChannel Den Namen der aufzurufenden Operation Die Endpunktreferenz des Partners Wird ein PartnerRoleMessageExchange Objekt an den Axis2 Integration Layer übergeben, erzeugt dieser (in der Klasse SoapExternalService) zunächst einen AxisService mit einer anonymen Operation. Für die anonyme Operation wird daraufhin ein OperationClient instantiiert, dessen execute Methode schließlich den Web Service Aufruf durchführt. Zuvor werden dem OperationClient jedoch die von der Runtime übergebene Nachricht, die Operation sowie die Endpunktreferenz zugewiesen. Wurde der Web Service Aufruf erfolgreich ausgeführt, konvertiert der Integration Layer die Antwortnachricht und gibt diese über die Methode reply des PartnerRoleMessageExchange Objekts an die Runtime Komponente zurück BPEL Runtime Die BPEL Runtime bildet die Ausführungsumgebung für kompilierte Prozesse. Neben der eigentlichen Ausführung von Prozessinstanzen ist sie ebenfalls dafür verantwortlich, Nachrichten an Prozessinstanzen weiterzuleiten oder bei Bedarf neue Prozessinstanzen zu erzeugen. Zudem implementiert sie Dienste, über die die Prozess und Prozessinstanzen der BPEL Engine verwaltet werden können. Im Folgenden werden die für die Diplomarbeit relevanten Subkomponenten der BPEL Runtime vorgestellt. 94

105 Kapitel 5: Entwurf & Implementierung JACOB Die Kernkomponente der BPEL Runtime bildet das sog. Java Concurrent Object (JACOB) Framework. JACOB stellt eine virtuelle Maschine bereit, die BPEL Aktivitäten ausführen und dabei ihren Zustand persistent speichern kann. Im Folgenden werden die Aspekte von JACOB erläutert, die für ein Verständnis der vorgenommenen Erweiterungen erforderlich sind. Für eine ausführlichere Beschreibung der Funktionsweise von JACOB wird auf [ODE] verwiesen. Jede Instanz einer BPEL Aktivität wird durch ein Objekt der entsprechenden Klasse (ASSIGN, PICK, INOKE,...) repräsentiert. Alle diese Klassen erben von der abstrakten Klasse BpelJacobRunnable und implementieren die darin definierte Methode run. Diese Methode wird von JACOB aufgerufen, sobald die Aktivität ausgeführt werden soll. Dementsprechend wird in der Methode die Logik der jeweiligen Aktivität implementiert. Strukturierte Aktivitäten, wie z.b. die scope Aktivität, erzeugen darin Instanzen ihrer untergeordneten Aktivitäten und übergeben diese JACOB zur Ausführung. Vor der Übergabe wird der Instanz ein ParentScopeChannel zugewiesen. Dieser bietet die Funktionen completed, compensation und failure, die je nach Ausführungsergebnis von der untergeordneten Aktivitätsinstanz aufgerufen werden. Tritt beispielsweise ein nicht bekannter Fehler auf, muss die untergeordnete Aktivität die Funktion failure aufrufen. Ist der Fehlertyp bekannt oder wurde die Aktivität erfolgreich ausgeführt, muss hingegen die Funktion completed mit den optionalen Fehlerdaten aufgerufen werden. Von der strukturierten Aktivität wird eine ParentScopeChannelListener erzeugt, der die Funktionsaufrufe überwacht und entsprechende Aktionen durchführt. Ruft eine untergeordnete Aktivität beispielsweise die Funktion compensate auf, so wird, falls vorhanden, der Compensation Handler der strukturierten Aktivität ausgeführt. DAOs Damit eine zuverlässige Ausführung von Prozessinstanz möglich ist, müssen Prozessinstanzdaten (Variablenwerte, Prozessinstanzdaten, etc.) persistent gespeichert werden. Zu diesem Zweck verwendet ODE Data Access Objects (DAOs, [SUN09]). DAOs abstrahieren und kapseln den Zugriff auf Datenquellen, wie z.b. relationale Datenbanken oder Dateien. ODE implementiert DAOs, die über Hibernate46 und Open JPA47 auf Datenbanken zugreifen. Zudem existiert eine Implementierung, die die Daten im Arbeitsspeicher hält und damit eine performantere, jedoch nicht persistente Ausführung von Prozessinstanzen erlaubt. Management & Event ODE stellt Managementfunktionen über zwei Dienste zur Verfügung. Über das Prozessmanagement können Prozesses aktiviert und deaktiviert sowie Informationen über Prozesse und deren Instanzen abgefragt werden. Das Instanzmanagement ermöglicht den Zugriff auf Daten einzelner Prozessinstanzen, Scopes und Aktivitäten. So können beispielsweise Ausführungszustände, Variablenwerte und Fehlerinformationen abgerufen werden. Ebenso ist es möglich, fehlgeschlagene Aktivitäten erneut ausführen zu lassen. Zudem bietet das Instanzmanagement eine Funktion, mit der Ereignisse einer Prozessinstanz abgefragt werden können ( ) ( ) 95

106 Kapitel 5: Entwurf & Implementierung Die Ereignisse werden dabei während der Ausführung der Prozessinstanz erzeugt und über das DAO des jeweiligen Prozessinstanz persistiert. Jedes Prozessinstanzereignis erbt von der serialisierbaren Klasse ProcessInstanceEvent. Instanzen von BPEL Aktivitäten lösen die Ereignisse über Aufrufe der Methode sendevent aus. 5.3 Sicherheitskomponente Um die Sicherheitsfunktionalität soweit wie möglich von der Kernfunktionalität der Engine getrennt zu halten, wurde im Rahmen der Diplomarbeit eine neue Komponente für ODE entwickelt. Die Komponente enthält alle sicherheitsrelevanten Schnittstellen und Klassen, die von der BPEL Engine zur Absicherung von Prozessen benötigt werden. Andere Engine-Komponenten können auf die Sicherheitskomponente zugreifen und für eine Umsetzung der Sicherheitsanforderungen sorgen (siehe 5.4). Bei der Konzipierung der Sicherheitskomponente wurde darauf geachtet, die Abhängigkeiten zu anderen Komponenten der ODE möglichst gering zu halten. Sie könnte daher ohne größeren Aufwand aus ODE herausgelöst und beispielsweise zur Absicherung normaler Web Services verwendet werden. Die Klassen und Schnittstellen der Sicherheitskomponente lassen sich den folgenden vier Bereichen zuordnen: Sicherheitsverwaltung Benutzerverwaltung Zugriffsrechteverwaltung Endpunkteverwaltung Diese werden im folgenden separat betrachtet Sicherheitsverwaltung Die Sicherheitsverwaltung beinhaltet die grundlegenden Schnittstellen zum Zugriff auf eine Security Domain. Die Schnittstelle MutableBpelSecurityManager ist dabei von zentraler Bedeutung: Sie repräsentiert den Verwalter der Sicherheitsdienste einer Security Domain. So können beispielsweise über die Methoden addidentityservice und removeidentityservice Identity Services zur Security Domain hinzugefügt bzw. aus der Security Domain entfernt werden. Zudem stellt die Schnittstelle Hilfsmethoden zum Zugriff auf die Security Domain bereit. Beispielsweise kann über die Methode finduser ein Benutzer innerhalb der Security Domain gesucht werden. Die Methode checkaccess dient hingegen dazu, die Zugriffsberechtigung eines Benutzers auf eine Ressource zu überprüfen. Neben dieser Schnittstelle sei noch die Schnittstelle SecurityManagement erwähnt. Diese definiert Methoden zur Verwaltung der Sicherheitseinstellungen von Prozessen. Die restlichen Schnittstellen der Sicherheitsverwaltung sind allgemeine Schnittstellen, von denen Dienste sowie Diensterzeuger (Factories) abgeleitet werden müssen (z.b. XMLObject, XMLObjectFactory). Alle Schnittstellen der Sicherheitsverwaltung befinden sich im Paket org.apache.ode.security. 96

107 Kapitel 5: Entwurf & Implementierung Im Rahmen der Diplomarbeit wurde eine Implementierung der Schnittstelle MutableBpelSecurityManager realisiert. Diese verwaltet die Angaben über eine Security Domain innerhalb einer Datei, dem sog. Security Descriptor (siehe 4.2.7). Im Folgenden wird die Struktur beschrieben, die dabei für den Security Descriptor festgelegt wurde. Anschließend wird erläutert, wie ein Security Descriptor und die darin definierten Dienste geladen und gespeichert werden Aufbau des Security Descriptors Listing 5.1 zeigt den Aufbau des Security Descriptors. 1 <security xmlns="http://www.apache.org/ode/security" 2 isenabled="{true} false"> 3 <identity-service factory="<factory_classname>" realm="<realm_name>"> 4 [Domain specific elements] 5 </identity-service> * 6 <authorization-service factory="<factory_classname>"> 7 [Domain specific elements] 8 </authorization-service>? 9 <endpoint-settings-service factory="<factory_classname>"> 10 [Domain specific elements] 11 </endpoint-settings-service>? 12 </security> Listing 5.1: Aufbau des Security Descriptors Das Wurzelelement security repräsentiert eine Security Domain, die über das optionale Attribut isenabled aktiviert oder deaktiviert werden kann (Standardwert: true ). Unter dem Wurzelelement werden alle Dienste der Security Domain in XML Elementen des entsprechenden Typs (identity-service, authorization-service etc.) definiert. Jedes dieser Elemente muss das Attribut factory enthalten, in dem der Name einer Java-Klasse angegeben ist, die den Dienst erzeugen kann. Bei Identity Services muss zusätzlich der Name eines Realms angegeben werden. Alle Benutzer und Rollen dieses Identity Services werden diesem Realm zugeordnet. Innerhalb des XML Elementes eines Dienste befinden sich domänenspezifische Elemente (Domain specific elements), die zur Erzeugung des jeweiligen Dienstes benötigt werden Laden und Speichern des Security Descriptors Beim Deployment eines Prozesses erzeugt die BPEL Engine aus dem zugeordneten Security Descriptor einen Security Manager (Klasse BpelSecurityManager). Der Security Manager instantiiert und kapselt die Dienste, die im Security Descriptor beschrieben sind. Zur Erzeugung der Dienste wird dabei das Factory Method Pattern [GHJ+94] angewendet: Zunächst wird eine Instanz der im factory-attribut angegebenen Klasse erzeugt. Diese Klasse muss zwingend die für den jeweiligen Diensttyp definierte FactorySchnittstelle (IdentityServiceFactory, AuthorizationServiceFactory etc.) implementieren. Über Methode load wird anschließend eine Instanz des Dienstes erzeugt. Als Parameter wird dabei das DOM Element des Dienstes, übergeben. Auf diese Weise kann die Factory bei der Erzeugung des Dienstes auf die domänenspezifischen Elemente innerhalb des Security Descriptors zugreifen. Der beschriebene Lademechanismus ermög- 97

108 Kapitel 5: Entwurf & Implementierung licht die einfache Integration eigener Implementierungen von Sicherheitsdiensten in die BPEL Engine. Wenn der BPEL Security Manager einen Dienst erzeugt, registriert er sich bei diesem als Observer. Dadurch kann ein Dienst dem Security Manager mitteilen, wenn sich seine XML Repräsentation geändert hat. Dies kann z.b. der Fall sein, wenn ein Identity Manager seine Benutzer- und Rolleninformationen direkt im Security Descriptor (innerhalb der domänenspezifischen Elemente) speichert und Benutzer oder Rollen geändert werden. Der BPEL Security Manager kann dann den Security Descriptor aktualisieren und persistent im Dateisystem speichern. Die Speicherung des Security Descriptors erfolgt mit Hilfe der Schnittstelle XMLObject, die alle Dienste implementieren. Die Schnittstelle verfügt über die Methode save, die der BPEL Security Manager bei einem Speichervorgang für alle Dienste aufruft. In der Methode erzeugt jeder Dienst eine XML Repräsentation, über die er durch den oben beschriebenen Mechanismus wieder geladen werden kann. Der BPEL Security Manager fügt die Strukturen zu einem XML Dokument zusammen und überschreibt damit den bisherigen Security Descriptor. Abbildung 5.2: Laden und Speichern des Security Descriptors Zur Implementierung der beschriebenen Funktionalität wurde das Proxy Pattern ([GHJ+94]) angewandt (siehe Abbildung 5.2): Die Klasse BpelSecurityManagerImpl repräsentiert einen statischen Security Manager. Ein statischer Security Manager kann einen Security Descriptor laden, aktualisiert diesen bei Änderungen jedoch nicht. Eine Instanz der Klasse UpdatingBpelSecurityManagerImpl (der Proxy) kapselt den statischen Security Manager und aktualisiert den Security Descriptor, falls Änderungen an dessen XML Struktur gemeldet werden. Zusätzlich überwacht die Klasse das Dateisystem, um externe Änderungen des Security Descriptors erkennen zu können. Tritt eine solche Änderung auf, wird ein neuer, statischer Security Manager erzeugt. Da von außen nur auf den Proxy zugegriffen wird, ist gewährleistet, dass bei Aufrufen immer die aktuellen Sicherheitseinstellungen des Prozesses verwendet werden. Müssen externe 98

109 Kapitel 5: Entwurf & Implementierung Komponenten auf Änderungen an den Sicherheitseinstellungen reagieren, können sich ebenfalls benachrichtigen lassen Benutzerverwaltung Alle Schnittstellen der Benutzerverwaltung befinden sich im Paket org.apache.ode.security.usermanagement. Sie definieren, wie einheitlich auf Rollen, Benutzer und Benutzereigenschaften eines Identity Services zugegriffen werden kann. Zudem werden Methoden bereitgestellt, die eine Verwaltung der Benutzer, Rollen und Rollenzugehörigkeiten erlauben. Über Implementierungen der Schnittstellen können Benutzer- und Rolleninformationen aus verschiedenen Quellen, wie z.b. Dateien oder Datenbanken, in die BPEL Engine eingebunden werden. Der Zugriff auf die Informationen erfolgt nach dem Data Access Object (DAO) Pattern (vgl. [SUN09]). Abbildung 5.3 zeigt anhand eines Sequenzdiagramms beispielhaft, wie auf Benutzerinformationen innerhalb eines LDAP Servers zugegriffen wird. Abbildung 5.3: Zugriff auf Eigenschaften eines LDAP Benutzers Ein Requestor möchte die Eigenschaft des Benutzers hr72si abfragen. Dazu ruft er zunächst die Funktion getuser des Objekts LdapIdentityService auf, welches einen Identity Service repräsentiert und dementsprechend die Schnittstelle IdentityService implementiert. Der Identity Service schickt eine Anfrage an den LDAP Server, mit der überprüft wird, ob der angegebene Benutzer existiert. Ist dies der Fall, erzeugt der Identity Service ein DAO (LdapUser), welches die Schnittstelle User implementiert. Dieses gibt er als Ergebnis der Funktion an den Requestor zurück. Der Requestor kann nun über das DAO Eigenschaften und Rollenzugehörigkeiten des Benutzers abrufen und verändern. Darüber hinaus ist über die Funktionen checkpassword und changepass- 99

110 Kapitel 5: Entwurf & Implementierung word eine Überprüfung bzw. Änderung des Passwortes möglich. Um die Performanz zu steigern, können Benutzereigenschaften innerhalb des DAOs gecached werden. Im Rahmen dieser Arbeit wurden drei verschiedene Implementierungen der Schnittstellen realisiert: Datei-interne Benutzerverwaltung: Paket: org.apache.ode.security.usermanagment.internal Ermöglicht den Zugriff und Verwaltung von Benutzern und Rollen, die innerhalb des Security Descriptors gespeichert werden. Datenbank-basierte Benutzerverwaltung: Paket: org.apache.ode.security.usermanagment.jdbc Ermöglicht den Zugriff und Verwaltung von Benutzern und Rollen die in einer Datenbank gespeichert werden. Die Datenbank wird über JDBC angesprochen. LDAP-basierte Benutzerverwaltung: Paket: org.apache.ode.security.usermanagment.ldap Ermöglicht den Zugriff und Verwaltung von Benutzer und Rollen, die auf einem LDAP-Server gespeichert werden. Listing 5.2 zeigt ein Beispiel für die Definition einer datei-internen Benutzerverwaltung. 1 <security xmlns="http://www.apache.org/ode/security"> 2 <identity-service factory="...management.internal.usermanagerimpl"> 3 <role id="diplomand"/> 4 <role id="praktikant"/> 5 <user id="hr72si"> 6 <property name="password" value="pw"/> 7 <property name="given name" value="heiko"/> 8 <property name="surname" value="görig"/> 9 <role>diplomand</role> 10 </user> 11 </identity-service> 12 [...] 13 </security> Listing 5.2: Datei-interne Benutzerverwaltung Um die Datenbank-basierte oder LDAP-basierte Benutzerverwaltung zu verwenden, müssen in den domänenspezifischen Elementen des Identity Services Eigenschaften angegeben werden, mit deren Hilfe eine Verbindung zu der Datenbank bzw. dem LDAP Server aufgebaut werden kann. Bei der LDAP-Benutzerverwaltung gehören dazu etwa die URL des LDAP Servers sowie Login-Informationen (siehe Listing 5.3). Zudem kann eingestellt werden, ob abgefragte Benutzer- und Rolleninformationen gecached werden sollen. 100

111 Kapitel 5: Entwurf & Implementierung 1 <security xmlns="http://www.apache.org/ode/security"> 2 <identity-service factory="...management.ldap.ldapusermanagerimpl"> 3 <property name="provider_url" value="ldap://localhost:389"/> 4 <property name="basedn" value="dc=example,dc=com"/> 5 <property name="is_cached" value="no"/> 6 <property name="security_principal" value="cn=directory Manager"/> 7 <property name="security_credentials" value="pw"/> 8 </identity-service> 9 [...] 10 </security> Listing 5.3: LDAP-basierte Benutzerverwaltung Zugriffsrechteverwaltung Die Zugriffsrechteverwaltung definiert Schnittstellen, über die Zugriffsrechte abgefragt und verwaltet werden können. Authorization Services implementieren diese Schnittstellen und können so beispielsweise Richtlinien aus Datenbanken in die BPEL Engine einbinden. Die Schnittstellen zur Verwaltung der Zugriffsrechte beschränken sich auf das Anlegen, Löschen und Verändern vereinfachter Access Control Lists (siehe Fehler: Referenz nicht gefunden). Der Zugriff auf Daten erfolgt wie in der Benutzerverwaltung über DAOs. Alternativ kann ein Authorization Service auch lediglich die Funktion hasaccess(user, resource) implementieren. In diesem Fall ist jedoch keine Verwaltung der Zugriffsberechtigungen über die BPEL Engine möglich (vgl ). Alle Schnittstellen der Zugriffsrechteverwaltung befinden sich im Paket org.apache.ode.security.authorization. Im Rahmen der Diplomarbeit wurde die folgende Zugriffsrechteverwaltung implementiert: Datei-interne Zugriffsrechteverwaltung: Paket: org.apache.ode.security.authorization.internal Ermöglicht die Abfrage und Verwaltung von Zugriffsrechten, die innerhalb des Security Descriptors gespeichert werden. Listing 5.4 liefert ein Beispiel für die Definition einer datei-internen Zugriffsrechteverwaltung. Der Authorization Service verfügt über eine Access Control List für den Endpunkt mit der Adresse Neben Benutzern mit den Rollen employee und salesman ist auch dem Benutzer hr72si ein Zugriff auf den Endpunkt gestattet. 1 <security xmlns="http://www.apache.org/ode/security"> 2 [...] 3 <authorization-service factory="...authorizationservicefactoryimpl"> 4 <acl resource="http://localhost/ode/processes/salesprocess"> 5 <role id="employee"/> 6 <role id="salesman"/> 7 <user id="hr72si"/> 8 </acl> 9 </authorization-service> 10 [...] 11 </security> Listing 5.4: Datei-interne Zugriffsrechteverwaltung 101

112 Kapitel 5: Entwurf & Implementierung Endpunkteverwaltung Die Endpunkteverwaltung spezifiziert Schnittstellen, über die ein Zugriff auf Sicherheitseinstellungen von Endpunkten möglich ist. Alle Schnittstellen der Endpunkteverwaltung befinden sich im Paket org.apache.ode.security.settings. Analog zur Benutzerund Zugriffsrechteverwaltung können der BPEL Engine durch Realisierungen der Schnittstellen Endpunkteinstellungen aus beliebigen Datenquellen verfügbar gemacht werden. Wiederum findet der Datenzugriff über DAOs statt. Exemplarisch wurde die folgende Endpunkteverwaltung implementiert: Datei-interne Endpunkteverwaltung: Paket: org.apache.ode.security.settings.internal Ermöglicht die Abfrage und Verwaltung von Sicherheitseinstellungen, die innerhalb des Security Descriptors gespeichert werden. Listing 5.5 zeigt einen entsprechenden Eintrag innerhalb eines Security Descriptors. Der Endpoint Settings Service verfügt hierbei über genau einen Keystore ( partnerkeystore, Zeile 4-7). Dieser wird innerhalb der Credentials salesservicecredentials referenziert (Zeile 11). Zusammen mit der Angabe im Element partnerkeyalias (Zeile 12) ergibt sich der Schlüssel, der dem Partner des Nachrichtenaustauschs zugeordnet ist (Schlüssel hans aus Keystore partnerkeystore ). Dieser Schlüssel wird entsprechend zur Verschlüsselung von Nachrichten eingesetzt. Als Benutzername und Passwort sollen die ID bzw. das Passwort des aktuellen Benutzers verwendet werden (Zeile 9+10). Das Element outbound in Zeile 14 legt die Sicherheitseinstellungen für Aufrufe des Dienstes {http://org.sales}salesservice fest. Hierbei sollen die oben beschriebenen Credentials verwendet werden (Zeile 15). Die über das Element policyfilepath referenzierte Datei enthält die Security Policy, die beim Aufruf des Endpunktes gelten soll (Zeile 16). 1 <security xmlns="http://www.apache.org/ode/security"> 2 [...] 3 <endpoint-settings-service factory="...ntsettingsservicefactoryimpl"> 4 <keystoreconfig name="partnerkeystore"> 5 <property name="file" value="partners.jks"/> 6 <property name="type" value="jks"/> 7 </keystoreconfig> 8 <credentials name="salesservicecredentials"> 9 <myusername>$id</myusername> 10 <mypassword>$password</mypassword> 11 <partnerkeystore>partnerkeystore</partnerkeystore> 12 <partnerkeyalias>hans</partnerkeyalias> 13 </credentials> 14 <outbound target="{http://org.sales}salesservice"> 15 <defaultcredentials>salesservicecredentials</defaultcredentials> 16 <policyfilepath>usernametoken_symmetric.xml<policyfilepath> 17 </outbound> 18 </endpoint-settings-service> 19 </security> Listing 5.5: Datei-interne Endpunkteverwaltung 102

113 Kapitel 5: Entwurf & Implementierung 5.4 Erweiterungen der Apache ODE Die bloße Existenz der Sicherheitskomponente ändert nichts an der Sicherheit einer BPEL Engine. Erst durch die Integration der Komponente in das bestehende System kann der gewünschte Effekt erzielt werden. Abbildung 5.4 gibt einen Überblick über die Änderungen, die an ODE im Zuge der Integration der Sicherheitskomponente vorgenommen wurden. Die Modifikationen der Komponenten werden nun jeweils einzeln betrachtet. Abbildung 5.4: Änderungen und Erweiterungen der BPEL Engine Apache ODE Deployment Unit & BPEL Compiler Die Deployment Unit wurde um den (optionalen) Security Descriptor erweitert. Der Security Descriptor kann einem Prozess dabei wie in beschrieben zugewiesen werden. Der Compiler wurde so modifiziert, dass er die in definierten Erweiterungsattribute runas und rolesallowed mit in das Prozessmodell integriert. Dazu wurde die Klasse OActivity entsprechend erweitert. Da es sich dabei um die Basisklasse für alle BPEL Aktivitäten handelt, kann die Funktionalität der Erweiterungsattribute durch geringfügige Anpassungen der Runtime Komponente relativ einfach auf andere Aktivitäten erweitert werden. Um Variablen über den Deployment Descriptor initialisieren zu können, wurde das Erweiterungsattribut initialvalue ebenfalls in das OModel integriert. Zudem 103

114 Kapitel 5: Entwurf & Implementierung wurden dem Compiler die in und definierten XPath-Variablen und XPathFunktionen bekanntgemacht Integration Layer Die Modifikation des Integration Layers ergaben sich im Wesentlichen durch die Anwendung der Sicherheitseinstellungen auf die Endpunkte der Prozesse. Um Änderungen an dem bestehenden Code so weit wie möglich zu vermeiden, wurde eine Großteil der Funktionalität in der Klasse AxisSecurityUtils ausgelagert. Die statische Funktion attachinboundsecurity sorgt etwa für die Absicherung eines bereitgestellten Endpunktes und dessen Operationen. Als Parameter müssen ihr dazu Objekte des Typs BpelSecurityManager und AxisService übergeben werden. Die Funktion iteriert durch alle Operationen des AxisService Objekts, ermittelt die jeweils geltenden Sicherheitseinstellungen und wendet diese auf die Operation an. Die Ermittlung der Sicherheitseinstellungen erfolgt über Funktionsaufrufe des BpelSecurityManagers, der die Anfragen wiederum an den gekapselten Endpoint Settings Service weiterreicht. Sind einer Operation Sicherheitseinstellungen zugeordnet (vgl ), so werden die folgenden Aktionen durchgeführt: 1. Die in den Sicherheitseinstellungen angegebene Policy wird mit Hilfe von Apache Neethi geladen (siehe 5.1.3). 2. Die Credentials der Sicherheitseinstellungen werden in die von Apache Rampart benötigte Policy Assertion konvertiert und der geladenen Policy hinzugefügt (siehe 5.1.2). 3. Die geladene Policy wird über die Methode applypolicy auf die Operation angewandt. 4. Es wird ein Callback Handler erzeugt (Klasse InboundCallbackHandler), der Rampart mit den in den Credentials angegebenen Passwörtern versorgt. Zudem ruft Rampart den Callback Handler zur Überprüfung von Benutzername/Passwort Angaben auf. In diesem Fall greift der Callback Handler über den BpelSecurityManager auf die Benutzer des Prozesses zurück und überprüft die angegebenen Credentials. 5. Der erzeugte Callback Handler wird der Operation zugewiesen. 6. Über die Methode engagemodule wird Rampart für die Operation eingeschaltet. Ist der Web Service, dem die Operation angehört, aktiviert, werden ein- und ausgehende Nachrichten der Operation von Rampart verarbeitet. Zusätzlich erzeugt die Funktion einen Listener, der Änderungen an den Sicherheitseinstellungen überwacht diese durch eine erneute Durchführung der oben genannten Aktionen auf den Endpunkt überträgt. Über die Methode detachinboundsecurity werden alle Sicherheitseinstellungen entfernt. Für ausgehende Web Services wird entsprechend die Methode attachoutboundsecurity zur Verfügung gestellt. Diese wird vor jedem Web Service Aufruf ausgeführt und konfiguriert den OperationClient (siehe 5.2.2) auf ähnliche Weise wie dies bei eingehenden Operationen der Fall ist. Im Gegensatz dazu werden jedoch zwei zusätzliche Aktionen 104

115 Kapitel 5: Entwurf & Implementierung durchgeführt. Zum einen wird über eine Anfrage an den Endpoint Settings Service ermittelt, ob für den aktuellen Benutzers eigene Credentials vorhanden sind. Ist dies der Fall, werden die Credentials anstelle der Standard-Credentials der Operation verwendet. Zum anderen findet eine Auflösung der Platzhalter innerhalb der Credentials statt (siehe 4.2.8). Neben den Funktionen zur Absicherung der Endpunkte, implementiert die Klasse AxisSecurityUtils ebenfalls die Funktion createusercontext. Diese erzeugt aus dem MessageContext einer eingehenden Nachricht ein User Element (siehe 4.3.1, 5.2.2). Dabei werden nicht nur der Name und das Realm des Benutzers, sondern auch weitere Benutzereigenschaften aus dem MessageContext extrahiert. Dies umfasst bisher die folgenden Eigenschaften: Die IP Adresse des Aufrufers. Der Domain Name des Benutzers, von dem die Nachricht signiert wurde. Name und Passwort, mit denen sich der Aufrufer über Basic Authentication 48 beim Web Server authentifiziert hat. Sind alle zusätzlichen Eigenschaften vorhanden, ähnelt das User Element dem aus Listing 5.6. Innerhalb der Prozessdefinition Prozessdefinition kann über die XPath-Funktion getuserproperty oder einen XPath-Ausdruck auf die Eigenschaften zugegriffen werden. Zudem können die Eigenschaften ebenfalls innerhalb von Platzhaltern verwendet werden (siehe 4.2.3, 4.3.5). 1 <user xmlns="http://www.apache.org/ode/security" 2 id="hr72si" realm="bosch.de"> 3 <attribute id="ip"> </attribute> 4 <attribute id="signatureusername"> 5 CN=hr72si, OU=EC, O=GS, ST=de, C=bosch 6 </attribute> 7 <attribute id="httpusername">admin</attribute> 8 <attribute id="httppassword">mypassword</attribute> 9 </user> Listing 5.6: User Element mit zusätzlichen Benutzerinformationen Zur Übergabe des User Elements an die Runtime Komponente wurde die Schnittstelle MessageExchange, und damit die davon abgeleitete Schnittstelle MyRoleMessageExchange, um die Methoden setusercontext und getusercontext erweitert. Da auch die Schnittstelle PartnerRoleMessageExchange von MessageExchange abgeleitet ist, kann der Benutzer umgekehrt auch von der Runtime Komponente an den Integration Layer übergeben werden (siehe 5.2.2) BPEL Runtime An der Runtime Komponente wurden umfangreichere Veränderungen vorgenommen. Um eingehende und ausgehende Nachrichten zu autorisieren, wurden an den entsprechenden Stellen Policy Enforcement Points implementiert. Darüber hinaus fand eine Implementierung der in 4.3 spezifizierten Erweiterungen statt. Zur Verwaltung der Si48 ( ) 105

116 Kapitel 5: Entwurf & Implementierung cherheitseinstellungen wurde ein neuer Managementdienst hinzugefügt. Die Benutzerschnittstelle der Engine wurde so erweitert, dass sie die Anwendungsfälle aus 4.4 abdeckt. Die Änderungen an den Subkomponenten werden im Folgenden separat betrachtet. JACOB Die Implementierung der Attribute rolesallowed und runas wurde über die zwei zusätzlichen Basisklassen SECUREDACTIVITY bzw. RUNASACTIVITY realisiert. Alle BPEL Aktivitäten, die das runas Attribut unterstützen, erben von RUNASACTIVITY, Aktivitäten, die lediglich das rolesallowed Attribut erlauben, von SECUREDACTIVITY. Innerhalb der Klassen wird die Funktionalität des jeweiligen Attributs implementiert. Hierbei werden ebenfalls die in spezifizierten Fehler und Ereignisse ausgelöst. Beispielsweise wird bei einer fehlgeschlagenen Rollenüberprüfung über den ParentScopeChannel der Fehler authorizationdenied zurückgegeben und ein ActivityAuthorizationDeniedEvent gesendet (über die Methode sendevent). In der RUNASACTIVITY findet eine Auflösung des Benutzers nach der Spezifikation aus statt. Bei der Erzeugung eines Scopes werden die zugeordneten Benutzerinformationen zusammen mit den bestehenden Daten des Scopes gespeichert. Zusätzlich erfolgt eine Initialisierung der mit dem initialvalue Attribut versehenen Variablen. Um das usercontext Attribut zu unterstützen, wurden weiterhin Modifikationen an der PICK Aktivität vorgenommen. Benutzerinformationen, die mit der eingehenden Nachricht der Aktivität verbunden sind, werden nun in die angegebene Variable kopiert. Die letzte Änderung betrifft die INVOKE Aktivität. Diese wurde so angepasst, dass sie bei Web Service Aufrufen zusätzlich den aktuellen Benutzer übergibt, so dass die Aufrufe im Namen dieses Benutzers ausgeführt werden können. Neben den Erweiterungsattribute wurden auch die in und spezifizierten XPath-Variablen und XPath-Funktionen implementiert. Hierzu mussten die Klassen JaxpVariableResolver und JaxpFunctionResolver entsprechend erweitert werden. DAOs Um Benutzerinformationen zusammen mit den Daten der Prozessinstanz speichern zu können, mussten verschiedene DAO Schnittstellen erweitert oder modifiziert werden. Die Funktionen createinstance und createscope der Schnittstellen ProcessDAO bzw. ProcessInstanceDAO wurden beispielsweise um den Parameter usercontext erweitert. Dadurch wird es ermöglicht, den Benutzerkontext von Prozessinstanzen und Scopes zu speichern. Damit dieser anschließend wieder abfragt werden kann, wurden die Schnittstellen ProcessInstanceDAO und ScopeDOA jeweils um die Funktion getusercontext ergänzt. Der Datenaustausch zwischen der BPEL Runtime und der Integrationskomponente findet ebenfalls über DAOs statt. Um dabei zusätzlich den Benutzerkontext transportieren zu können, wurde die dafür verwendete Schnittstelle MessageExchangeDAO um die Funktionen setusercontext und getusercontext erweitert. Alle Implementierungen der DAO Schnittstellen (Hibernate, Open JPA und InMemory) wurden entsprechend nachgezogen. 106

117 Kapitel 5: Entwurf & Implementierung Management & Events Um die Sicherheitseinstellungen von Prozessen verwalten zu können, wurde die ODE um einen Security Management Web Service erweitert. Die Implementierung des Web Services (Klasse SecurityManagementImpl) stellt alle Funktionen bereit, die zur Verwaltung der Sicherheitseinstellungen von Prozessen benötigt werden. Dabei werden die übergebenen Einstellungen jeweils an die entsprechenden Sicherheitsdienste weitergereicht. Dies wird exemplarisch anhand der Funktion createuser(pid, realm, userid, password) gezeigt: Bei einem Aufruf der Funktion wird zunächst die Prozessdefinition des Prozesses mit der ID pid abgefragt. Anhand der Prozessdefinition wird der Security Manager des Prozesses ermittelt. Über den Security Manager wird anschließend der Identity Service abgefragt, der für das angegebene realm zuständig ist. Daraufhin wird die Methode createuser(userid) des Identity Services aufgerufen, die zur Erzeugung des Benutzers führt und als Ergebnis das DAO des Benutzers zurückgibt. Der letzte Schritt der Funktion besteht aus dem Aufruf der Methode changepassword des DAOs, mit dem das übergebene Passwort als Passwort des Benutzers festgelegt wird. Zur Verwendung der Web Service Funktionen des Security Managements wurde das Browser Interface der ODE um eine Seite für Sicherheitseinstellungen erweitert. Die Seite wird clientseitig mit JavaScript erzeugt und ruft Funktionen des Web Services auf. Sie deckt alle Anwendungsfälle aus 4.4 ab. Eine Gesamtansicht der Seite ist in Abbildung A1 dargestellt. Die Abbildung A2 A7 zeigen die Unteransichten der Benutzer-, Zugriffsrechte- und Endpunktverwaltung. Es macht wenig Sinn, einen Prozess abzusichern, solange der Web Service, über den die Sicherheit des Prozesses konfiguriert wird, öffentlich zugänglich ist. Aus diesem Grund wurde eine Möglichkeit geschaffen, mit dem die Management-Dienste der ODE ebenfalls abgesichert werden können: Ist ein Security Descriptor (Dateiname security.xml ) im Basisverzeichnis der Engine abgelegt, so wird dieser von der Engine geladen und auf die Endpunkte der Management-Dienste angewandt. Wie bei den Endpunkten von Prozessen wird daraufhin eine Verschlüsselung, Authentifizierung und Autorisierung von Nachrichten durchgeführt. Die Management-Dienste müssen dann jedoch von Hand aufgerufen werden, da das Browser Interface bisher weder WS-SecurityPolicy noch WS-Security unterstützt. Für einen solchen manuellen Aufruf kann beispielsweise soapui49 oder der auf der folgenden Seite beschriebene Web Service Caller (siehe 5.5) verwendet werden. Um auf fehlgeschlagene Autorisierungen reagieren zu können, wurden die Ereignisse ProcessAuthorizationDeniedEvent und ActivityAuthorizationDeniedEvent hinzugefügt. Die Ereignisse werden ausgelöst, wenn eine Autorisierung vor bzw. während der Ausführung einer Prozessinstanz fehlschlägt. 49 ( ) 107

118 Kapitel 5: Entwurf & Implementierung 5.5 Web Service Caller Um abgesicherte Prozesse und Web Services clientseitig aufrufen und testen zu können, wurde im Rahmen der Diplomarbeit eine Java Anwendung namens Web Service Caller entwickelt (siehe Abbildung A.8). Im Gegensatz zu anderen Web Service Testing Tools, wie z.b. soapui, verwendet der Web Service Caller Informationen aus Security Policies zum Aufruf abgesicherter Web Services. Dies vereinfacht den Test von Web Services und Security Policies erheblich. So müssen in soapui beispielsweise alle Sicherheitseinstellungen eines Web Service Aufrufs, wie z.b. die zu verwendenden Algorithmen oder die zu verschlüsselnden Nachrichtenteile, von Hand konfiguriert werden. Dies erübrigt sich beim Web Service Caller. Der Anwender muss stattdessen lediglich die für den Aufruf benötigten Credentials angeben. Die Struktur der Credentials entspricht dabei der aus Um Credentials wiederverwenden zu können, werden diese unabhängig von den aufzurufenden Web Service konfiguriert und können über einen eindeutigen Bezeichner referenziert werden. Ein typischer Web Service Aufruf verläuft mit Hilfe des Web Service Callers wie folgt: 1. Der Anwender lädt über die Angabe einer lokalen Datei oder einer URL die WSDL Definition eines Web Services. 2. Der Anwender wählt aus der Liste der Endpunkte den aufzurufenden Endpunkt aus. 3. Der Anwender wählt aus der Liste der Operationen die aufzurufende Operation aus. 4. Der Anwender wählt aus der Liste der Credentials die zu verwendenden Credentials aus. Sind keine passenden Credentials vorhanden, erzeugt der Benutzer in der Ansicht Credentials geeignete Credentials und wählt diese anschließend aus. 5. Der Anwender verändert im Eingabebereich den Payload der Request-Nachricht. 6. Der Anwender klickt auf Schaltfläche Aufrufen und startet damit den Web Service Aufruf. Die Antwortnachricht wird nach Beendigung des Web Service Aufrufs im Ausgabebereich angezeigt. Der Aufruf von Web Services erfolgt mit Hilfe von Axis2 und Rampart. Zur Verwaltung von Credentials und Keystores greift der Web Service Caller hingegen auf Klassen der für ODE entwickelten Sicherheitskomponente zurück. Um den Test von Web Services komfortabler zu gestalten, wurden zudem die folgenden Funktionalitäten implementiert: Erzeugte Credentials und Keystores, sowie die Adressen geladener WSDL Definitionen werden innerhalb einer Konfigurationsdatei gespeichert. Der Payload von Request-Nachrichten wird, abhängig von den Parametern der aufzurufenden Operation, automatisch generiert. Geladene WSDL Definitionen können in einem separaten Fenster angezeigt werden. Neben abgesicherten Web Services können auch nicht abgesicherte sowie REST basierte Web Services aufgerufen werden. 108

119 Kapitel 6: Zusammenfassung Kapitel 6 Zusammenfassung Im Rahmen dieser Diplomarbeit wurde untersucht, wie eine kontextbezogene Zugriffskontrolle für BPEL Prozesse realisiert werden kann. Zudem wurden weitere Sicherheitsaspekte von BPEL Engines, wie etwa der Aufruf abgesicherter Web Services oder die Speicherung von Benutzerinformationen, betrachtet. Aufgrund dieser Untersuchungen wurde ein umfangreiches Sicherheitskonzept für BPEL Engines entworfen und prototypisch für die Apache Orchestration Director Engine implementiert. Dabei wurde zunächst ermittelt, welche Sicherheitsanforderungen allgemein in verteilten Softwareumgebungen bestehen und wie diese erfüllt werden können. Anhand eines Beispielprozesses wurde anschließend analysiert, wo entsprechende Sicherheitsanforderungen in BPEL Prozessen auftreten und wie eine BPEL Engine diese erfüllen kann. Hierbei wurden verschiedene Lösungsansätze für Teilbereiche wie Authentifizierung, Autorisierung oder die Weitergabe von Benutzerinformationen entwickelt und diskutiert. Die Lösungsansätze bildeten die Grundlage für den praktischen Teil der Diplomarbeit, der aus dem Entwurf und der Implementierung des Sicherheitskonzepts besteht. Für Apache ODE wurde eine Sicherheitskomponente entwickelt, mit der unterschiedliche Sicherheitsdienste in die BPEL Engine eingebunden und Prozesse individuell abgesichert werden können. Die Sicherheitsumgebung eines Prozesses wird dabei über eine spezielle Datei, den Security Descriptor, definiert. Zur Absicherung der Kommunikation von Prozessen wird auf die Standards WS-Security und WS-SecurityPolicy zurückgegriffen. Im Zuge der Integration der Sicherheitskomponente wurden zahlreiche Erweiterungen an der Engine vorgenommen. So ist es nun beispielsweise möglich, Web Services aufzurufen, die mit WS-Security gesichert sind. Dabei können für einen Aufruf statische Credentials festgelegt werden. Darüber hinaus ist die Engine jedoch auch so konfigurierbar, dass Credentials eines Benutzers der aufrufenden Prozessinstanz verwendet werden. Um dies zu ermöglichen, mussten die von der BPEL Engine gespeicherten Prozessinstanzdaten um Benutzerinformationen erweitert werden. Außerdem wurden BPEL Erweiterungen implementiert, die eine Zuweisung von Benutzern zu Aktivitäten sowie einen Zugriff auf den Benutzer- und Sicherheitskontext einer Prozessinstanz ermöglichen. Zusätzliche Fehlerfälle und Ereignisse erlauben die Behandlung fehlgeschlagener 109

120 Kapitel 6: Zusammenfassung Autorisierungen und anderer sicherheitsrelevanter Ereignisse innerhalb bzw. außerhalb von BPEL. Das Browser Interface der Engine wurde ebenfalls erweitert und ermöglicht nun eine zentrale Konfiguration der Sicherheit von Prozessen. So kann die Sicherheit eines Prozesses global aktiviert oder deaktiviert werden. Zudem ist ein Prozessadministrator in der Lage, Sicherheitsdienste eines Prozesses auszutauschen sowie die Daten der Sicherheitsdienste zu verwalten. Benutzer, Rollen, Berechtigungen und Endpunkteinstellungen können hinzugefügt, verändert und gelöscht werden. Alle Änderungen an den Sicherheitseinstellungen eines Prozesses werden von der BPEL Engine unmittelbar in die Prozessausführung übernommen. Durch die beschriebenen Erweiterungen wurde eine kontextbezogene Zugriffskontrolle für Prozesse der Apache Orchestration Director Engine ermöglicht. Die vorgegebenen Ziele der Diplomarbeit wurden damit in vollem Umfang erreicht. 6.1 Ausblick Der dynamische Lademechanismus des Security Descriptors sowie das für Sicherheitsdienste verwendete Konzept der Service Abstraction erlaubt eine einfache Integration eigener Sicherheitsdienste in die BPEL Engine. Entsprechend können weitere Sicherheitsdienste für Apache ODE implementiert werden. So bietet sich beispielsweise die Entwicklung eines auf XACML basierenden Authorization Services an, durch den sich komplexere Richtlinien realisieren lassen. Zudem können Sicherheitsdienste implementiert werden, die als Adapter zu existierenden Diensten (z.b. Web Services) fungieren. Um zusätzliche Sicherheitsfunktionalitäten in die BPEL Engine einzubinden, können weitere Dienstarten spezifiziert und in die Sicherheitskomponente sowie den Security Descriptor integriert werden. Beispielsweise kann eine Schnittstelle für Authentication Services hinzugefügt werden. Durch Implementierungen der Schnittstelle lassen sich dann etwa Authentifizierungen über SAML Tokens oder Kerberos Tickets realisieren. Analog können die Einstellungsmöglichkeiten von ausgehenden Endpunkte so erweitert werden, dass zusätzliche Authentifizierungsarten, wie z.b. Single Sign-On oder HTTP Authentication50, möglich sind. Um Prozessmodellierern einen erweiterten Zugriff auf den Benutzer- und Sicherheitskontext einer Prozessinstanz zu erlauben, können zusätzliche BPEL Erweiterungen implementiert werden. Beispielsweise sind XPath-Funktionen denkbar, die Benutzereigenschaften ändern, neue Benutzer anlegen oder Berechtigungen erteilen. 50 ( ) 110

121 Anhang A Anhang A Grafische Oberflächen Abbildung A.1: Apache ODE Security Settings: Hauptansicht 111

122 Anhang A Abbildung A.2: Apache ODE Security Settings: Benutzerverwaltung Abbildung A.3: Apache ODE Security Settings: Zugriffsrechteverwaltung Abbildung A.4: Apache ODE Security Settings: Endpunkteverwaltung (1) 112

123 Anhang A Abbildung A.5: Apache ODE Security Settings: Endpunkteverwaltung (2) Abbildung A.6: Apache ODE Security Settings: Endpunkteverwaltung (3) Abbildung A.7: Apache ODE Security Settings: Endpunkteverwaltung (4) 113

124 Anhang A Abbildung A.8: Web Service Caller 114

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

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

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

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

(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

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

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

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

Denn es geht um ihr Geld:

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

Mehr

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

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

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

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

SSL-Protokoll und Internet-Sicherheit

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

Mehr

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

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

Ö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

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

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

Mehr

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

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

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

Verschlüsselung der Kommunikation zwischen Rechnern

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

Mehr

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

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

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

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

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

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

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

Verschlüsselungsverfahren

Verschlüsselungsverfahren Verschlüsselungsverfahren Herrn Breder hat es nach dem Studium nach München verschlagen. Seine Studienkollegin Frau Ahrend wohnt in Heidelberg. Da beide beruflich sehr stark einspannt sind, gibt es keine

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

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

Digital Signature and Public Key Infrastructure

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

Mehr

.NET-Networking 2 Windows Communication Foundation

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

Mehr

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

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

Mehr

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

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

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

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

Mehr

Digital Rights Management (DRM) Verfahren, die helfen Rechte an virtuellen Waren durchzusetzen. Public-Key-Kryptographie (2 Termine)

Digital Rights Management (DRM) Verfahren, die helfen Rechte an virtuellen Waren durchzusetzen. Public-Key-Kryptographie (2 Termine) Digital Rights Management (DRM) Verfahren, die helfen Rechte an virtuellen Waren durchzusetzen Vorlesung im Sommersemester 2010 an der Technischen Universität Ilmenau von Privatdozent Dr.-Ing. habil. Jürgen

Mehr

Sichere Abwicklung von Geschäftsvorgängen im Internet

Sichere Abwicklung von Geschäftsvorgängen im Internet Sichere Abwicklung von Geschäftsvorgängen im Internet Diplomarbeit von Peter Hild Theoretische Grundlagen der Kryptologie Vorhandene Sicherheitskonzepte für das WWW Bewertung dieser Konzepte Simulation

Mehr

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

Mehr

Service Oriented Architecture. IM-Briefing 2008 4. Dezember 2008

Service Oriented Architecture. IM-Briefing 2008 4. Dezember 2008 Service Oriented Architecture IM-Briefing 2008 4. Dezember 2008 Agenda Begrüssung Was ist SOA Herkunft Player Modell Komponenten Zusammenfassung Diskussion Seite 1 Was ist SOA? Herkunft Der Begriff serviceorientierte

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

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

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

Mehr

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

Grundlagen des Grid Computing

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

Mehr

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

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

IT-Sicherheit - Sicherheit vernetzter Systeme -

IT-Sicherheit - Sicherheit vernetzter Systeme - IT-Sicherheit - Sicherheit vernetzter Systeme - Kapitel 2: Grundlagen Helmut Reiser, LRZ, WS 08/09 IT-Sicherheit 1 Kapitel 2: Inhalt 1. Überblick über die OSI-Sicherheitsarchitektur 2. ISO/OSI Referenzmodell

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

Workflow, Business Process Management, 4.Teil

Workflow, Business Process Management, 4.Teil Workflow, Business Process Management, 4.Teil 24. Januar 2004 Der vorliegende Text darf für Zwecke der Vorlesung Workflow, Business Process Management des Autors vervielfältigt werden. Eine weitere Nutzung

Mehr

Secure Socket Layer V.3.0

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

Mehr

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

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

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

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

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

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

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

Mehr

Content-Verwertungsmodelle und ihre Umsetzung in mobilen Systemen

Content-Verwertungsmodelle und ihre Umsetzung in mobilen Systemen Content-Verwertungsmodelle und ihre Umsetzung in mobilen Systemen Digital Rights Management 4FriendsOnly.com Internet Technologies AG Vorlesung im Sommersemester an der Technischen Universität Ilmenau

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

Ich hab doch nichts zu verbergen... Der gläserne Bürger: Wieviel Daten braucht der Staat?

Ich hab doch nichts zu verbergen... Der gläserne Bürger: Wieviel Daten braucht der Staat? 1 / 32 Veranstaltungsreihe Ich hab doch nichts zu verbergen... Der gläserne Bürger: Wieviel Daten braucht der Staat? Veranstalter sind: 15. Mai bis 3. Juli 2008 der Arbeitskreis Vorratsdatenspeicherung

Mehr

SSL Algorithmen und Anwendung

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

Mehr

Secure Socket Layer v. 3.0

Secure Socket Layer v. 3.0 Konzepte von Betriebssystem-Komponenten Schwerpunkt Internetsicherheit Secure Socket Layer v. 3.0 (SSLv3) Zheng Yao 05.07.2004-1 - 1. Was ist SSL? SSL steht für Secure Socket Layer, ein Protokoll zur Übertragung

Mehr

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

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

TLS ALS BEISPIEL FÜR EIN SICHERHEITSPROTOKOLL

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

Mehr

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

E-Mails versenden aber sicher!

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

Mehr

Dynamische Web-Anwendung

Dynamische Web-Anwendung Dynamische Web-Anwendung Christiane Lacmago Seminar Betriebssysteme und Sicherheit Universität Dortmund WS 02/03 Gliederung Einleitung Definition und Erläuterung Probleme der Sicherheit Ziele des Computersysteme

Mehr

Virtuelle Netze. Virtuelle Netze von Simon Knierim und Benjamin Skirlo 1 Von 10-16.04.07. Simon Knierim & Benjamin Skirlo.

Virtuelle Netze. Virtuelle Netze von Simon Knierim und Benjamin Skirlo 1 Von 10-16.04.07. Simon Knierim & Benjamin Skirlo. 1 Von 10-16.04.07 Virtuelle Netze Simon Knierim & Benjamin Skirlo für Herrn Herrman Schulzentrum Bremen Vegesack Berufliche Schulen für Metall- und Elektrotechnik 2 Von 10-16.04.07 Inhaltsverzeichnis Allgemeines...

Mehr

Identity Management Service-Orientierung. 27.03.2007 Martin Kuppinger, KCP mk@kuppingercole.de

Identity Management Service-Orientierung. 27.03.2007 Martin Kuppinger, KCP mk@kuppingercole.de Identity Management Service-Orientierung 27.03.2007 Martin Kuppinger, KCP mk@kuppingercole.de Das Extended Enterprise verändert den Umgang mit Identitäten und Sicherheit Mitarbeiter Kunden Lieferanten

Mehr

Datensicherheit. Vorlesung 5: 15.5.2015. Sommersemester 2015 h_da. Heiko Weber, Lehrbeauftragter

Datensicherheit. Vorlesung 5: 15.5.2015. Sommersemester 2015 h_da. Heiko Weber, Lehrbeauftragter Datensicherheit Vorlesung 5: 15.5.2015 Sommersemester 2015 h_da, Lehrbeauftragter Inhalt 1. Einführung & Grundlagen der Datensicherheit 2. Identitäten / Authentifizierung / Passwörter 3. Kryptografie 4.

Mehr

Internet Security: Verfahren & Protokolle

Internet Security: Verfahren & Protokolle Internet Security: Verfahren & Protokolle 39 20 13 Vorlesung im Grundstudium NWI (auch MGS) im Sommersemester 2003 2 SWS, Freitag 10-12, H10 Peter Koch pk@techfak.uni-bielefeld.de 30.05.2003 Internet Security:

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

Multicast Security Group Key Management Architecture (MSEC GKMArch)

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

Mehr

Virtual Private Networks. Hans Peter Dittler BRAINTEC Netzwerk-Consulting GmbH

Virtual Private Networks. Hans Peter Dittler BRAINTEC Netzwerk-Consulting GmbH Virtual Private Networks Hans Peter Dittler BRAINTEC Netzwerk-Consulting GmbH Inhalt Einleitung Grundlagen Kryptographie IPSec Firewall Point-to-Point Tunnel Protokoll Layer 2 Tunnel Protokoll Secure Shell

Mehr

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

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

Mehr

ISSS Security Lunch - Cloud Computing

ISSS Security Lunch - Cloud Computing ISSS Security Lunch - Cloud Computing Technische Lösungsansätze Insert Andreas Your Kröhnert Name Insert Technical Your Account Title Manager Insert 6. Dezember Date 2010 The Cloud Unternehmensgrenzen

Mehr

SOA goes real Service-orientierte Architekturen erfolgreich planen und einführen

SOA goes real Service-orientierte Architekturen erfolgreich planen und einführen Daniel Liebhart SOA goes real Service-orientierte Architekturen erfolgreich planen und einführen ISBN-10: 3-446-41088-0 ISBN-13: 978-3-446-41088-6 Inhaltsverzeichnis Weitere Informationen oder Bestellungen

Mehr

Orchestrierung der IT-Sicherheit

Orchestrierung der IT-Sicherheit Orchestrierung der IT-Sicherheit Wie sieht es mit der Oracle Fusion Middleware aus? Mohammad Esad-Djou, Solution Architect OPITZ CONSULTING Deutschland GmbH München, 06. März 2014, Regionaltreffen München/Südbayern

Mehr

NAT & VPN. Adressübersetzung und Tunnelbildung. Bastian Görstner

NAT & VPN. Adressübersetzung und Tunnelbildung. Bastian Görstner Adressübersetzung und Tunnelbildung Bastian Görstner Gliederung 1. NAT 1. Was ist ein NAT 2. Kategorisierung 2. VPN 1. Was heißt VPN 2. Varianten 3. Tunneling 4. Security Bastian Görstner 2 NAT = Network

Mehr

Verschlüsselung und Signatur

Verschlüsselung und Signatur Verschlüsselung und Signatur 1 Inhalt Warum Verschlüsseln Anforderungen und Lösungen Grundlagen zum Verschlüsseln Beispiele Fragwürdiges rund um das Verschlüsseln Fazit Warum verschlüsseln? Sichere Nachrichtenübertragung

Mehr

Guten Tag! CampusSource. Die CSE Integration Platform. CampusSource Engine. Christof Pohl Softwareentwicklung Medienzentrum Universität Dortmund

Guten Tag! CampusSource. Die CSE Integration Platform. CampusSource Engine. Christof Pohl Softwareentwicklung Medienzentrum Universität Dortmund Engine Die CSE Integration Platform Guten Tag! Christof Pohl Softwareentwicklung Medienzentrum Universität Dortmund Integriertes Informationsmanagement mit der Engine - A2A vs. EBI Folie 2 Integration

Mehr

Autorisierung zentral steuern

Autorisierung zentral steuern Autorisierung zentral steuern AdNovum hatte jüngst Gelegenheit, ein Autorisierungs-Management-System für ein Gesundheits-Enterprise-Portal zu bauen. Welche Form der Autorisierung soll auf welcher Stufe

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

Rechneranmeldung mit Smartcard oder USB-Token

Rechneranmeldung mit Smartcard oder USB-Token Rechneranmeldung mit Smartcard oder USB-Token Verfahren zur Authentifizierung am Rechnersystem und angebotenen Diensten, SS2005 1 Inhalt: 1. Systemanmeldung 2. Grundlagen 3. Technik (letzte Woche) 4. Standards

Mehr

Business Process Execution Language. Christian Vollmer Oliver Garbe

Business Process Execution Language. Christian Vollmer <christian.vollmer@udo.edu> Oliver Garbe <oliver.garbe@udo.edu> Business Process Execution Language Christian Vollmer Oliver Garbe Aufbau Was ist BPEL? Wofür ist BPEL gut? Wie funktioniert BPEL? Wie sieht BPEL aus?

Mehr

Secure E-Mail der Suva

Secure E-Mail der Suva Secure E-Mail der Suva Informationsbroschüre für Entscheidungsträger und IT-Verantwortliche SEM_Informationsbroschuere_06-2013_de / WasWoShop: 2979/1.D 1 Inhaltsverzeichnis Secure E-Mail der Suva auf einen

Mehr

IT-Sicherheit Kapitel 11 SSL/TLS

IT-Sicherheit Kapitel 11 SSL/TLS IT-Sicherheit Kapitel 11 SSL/TLS Dr. Christian Rathgeb Sommersemester 2014 1 Einführung SSL/TLS im TCP/IP-Stack: SSL/TLS bietet (1) Server-Authentifizierung oder Server und Client- Authentifizierung (2)

Mehr

NorCom Global Security for BEA. Mehr Sicherheit für Web-Applikationen

NorCom Global Security for BEA. Mehr Sicherheit für Web-Applikationen NorCom Global Security for BEA Mehr Sicherheit für Web-Applikationen E-Business oder kein Business immer mehr Unternehmen verlagern ihre Geschäftsprozesse ins Internet. Dabei kommt dem Application Server

Mehr

Smartcard-Authentifizierung mit Oracle-Forms

Smartcard-Authentifizierung mit Oracle-Forms Smartcard-Authentifizierung mit Oracle-Forms Teil 1: Theoretisches zur 2-Faktor Authentifizierung Das Smartcard-Projekt der Nordrheinischen Ärzteversorgung Irisstrasse 45 11. November 2004 1 Inhalt Kurzvorführung

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

SICHERE DATENHALTUNG IN DER CLOUD VIA HANDY. Tuba Yapinti Abschlussvortrag der Bachelorarbeit Betreuer: Prof. Reinhardt, Dr.

SICHERE DATENHALTUNG IN DER CLOUD VIA HANDY. Tuba Yapinti Abschlussvortrag der Bachelorarbeit Betreuer: Prof. Reinhardt, Dr. SICHERE DATENHALTUNG IN DER CLOUD VIA HANDY 1 Tuba Yapinti Abschlussvortrag der Bachelorarbeit Betreuer: Prof. Reinhardt, Dr. Bernd Borchert GLIEDERUNG 1. Motivation Gründe für die Entwicklung Ideen für

Mehr

SOA Serviceorientierte Architektur Definition, Marktpotenzial und Perspektiven

SOA Serviceorientierte Architektur Definition, Marktpotenzial und Perspektiven SOA Serviceorientierte Architektur Definition, Marktpotenzial und Perspektiven SO A Fraunhofer-Institut für Softwareund Systemtechnik ISST Dr. Ulrich Springer Dr. Bernhard Holtkamp Dortmund, 20.01.2009

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

EAI - Enterprise Application Integration

EAI - Enterprise Application Integration EAI - Enterprise Application Integration Jutta Mülle WS 2005/2006 EAI - Folie 1 Überblick und Begriffsbildung Zusammenfassung und Ausblick hinweise EAI - Folie 2 Conclusion EAI Enterprise Application Integration

Mehr

Seminar Internet-Technologie

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

Mehr

Web Services: Inhalt

Web Services: Inhalt Web Services Fachseminar Verteilte Systeme 8. April 2002 - Marco Steiner Assistent: Thomas Schoch Professor: Dr. F. Mattern Web Services: Inhalt Bedeutung Gegenwart Architektur SOAP WSDL UDDI Vergleich

Mehr

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

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

Mehr