Service Oriented Architecture

Seminararbeit im StudiengangM.Sc. IT-Management and Information Systems

an derFachhochschule der Wirtschaft (FHDW)

Service Oriented Architecture

Vorgelegt von:

Björn Schrader und René Büst

Prüfer:

Prof. Dr. Eckhardt Koch

Eingereicht am:

18. Juli 2009

Verzeichnisse i

Inhaltsverzeichnis

Inhaltsverzeichnis I

Abbildungsverzeichnis IV

1 Thematische Einleitung 11.1 Thematische Gliederung . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Thematische Abgrenzung . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2 SOA Einleitung 1

3 Situationsanalyse 33.1 Architektur vor der SOA Einführung . . . . . . . . . . . . . . . . . . . . 33.2 Architektur nach der SOA Einführung . . . . . . . . . . . . . . . . . . . 33.3 Vergleich der Architekturen . . . . . . . . . . . . . . . . . . . . . . . . . 4

4 SOA Strategie 54.1 Ziele einer SOA Strategie . . . . . . . . . . . . . . . . . . . . . . . . . . 54.2 Betriebswirtschaftliche Analyse der SOA Strategie . . . . . . . . . . . . 5

4.2.1 Besserer ROI für bestehende IT-Systeme . . . . . . . . . . . . . 64.2.2 Verbesserte Kundenzufriedenheit . . . . . . . . . . . . . . . . . 74.2.3 Bessere Abstimmung von IT- und Business-Zielen . . . . . . . . 7

4.3 Technische Analyse der SOA Strategie . . . . . . . . . . . . . . . . . . . 84.3.1 Technische Eigenschaften . . . . . . . . . . . . . . . . . . . . . 84.3.2 Technische Vorteile nach Einführung einer SOA . . . . . . . . . 9

5 Erkenntnisse der SOA Strategie 105.1 Bekannte Probleme bei der Einführung einer SOA . . . . . . . . . . . . . 105.2 Bekannte Missverständnisse zum Thema SOA . . . . . . . . . . . . . . . 12

5.2.1 "Wenn du SOA einführst, sind alle deine Komponenten automa-tisch kompatibel zu einander" [SoaThe] . . . . . . . . . . . . . . 12

5.2.2 "Wenn du Web Services verstehst, hast du keine Probleme eineSOA aufzubauen." [SoaThe] . . . . . . . . . . . . . . . . . . . . 12

5.2.3 "SOA löst fachliche Probleme" [SoaThe] . . . . . . . . . . . . . 13

6 SOA und der Bezug zu E-Business 13

Verzeichnisse ii

7 Unternehmen und deren SOA Einsatz 147.1 Deutsche Post Brief . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147.2 Gründe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147.3 Ziele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147.4 Umsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157.5 Nutzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

7.5.1 Wiederverwendung von Services und Vermeidung redundanterSoftwareentwicklung . . . . . . . . . . . . . . . . . . . . . . . . 16

7.5.2 Kürzere Projektlaufzeiten und schneller Time-To-Market . . . . . 177.5.3 Niedrigere Wartungskosten . . . . . . . . . . . . . . . . . . . . . 177.5.4 Bessere Reaktionsfähigkeit auf neue Geschäftsanforderungen . . 17

8 SOA & Sicherheit 188.1 Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

8.1.1 Authentifizierung . . . . . . . . . . . . . . . . . . . . . . . . . . 188.1.2 Autorisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188.1.3 Vertraulichkeit/ Privatsphäre . . . . . . . . . . . . . . . . . . . . 188.1.4 Integrität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188.1.5 Verfügbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

8.2 Risiken & Bedrohungen . . . . . . . . . . . . . . . . . . . . . . . . . . 198.2.1 Replay Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . 198.2.2 XML Spezifische Angriffe . . . . . . . . . . . . . . . . . . . . . 198.2.3 WSDL- und Service Scanning . . . . . . . . . . . . . . . . . . . 218.2.4 Kompromittierung eines Service . . . . . . . . . . . . . . . . . . 218.2.5 Unberechtigte Servicenutzung . . . . . . . . . . . . . . . . . . . 21

8.3 Konzepte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218.3.1 Sicherheit auf Transportebene . . . . . . . . . . . . . . . . . . . 218.3.2 Sicherheit auf Nachrichtenebene . . . . . . . . . . . . . . . . . . 228.3.3 XML-Firewalls/ XML-Gateways . . . . . . . . . . . . . . . . . . 238.3.4 Sicherheit auf Fachlicher Ebene . . . . . . . . . . . . . . . . . . 238.3.5 Applikationssicherheit . . . . . . . . . . . . . . . . . . . . . . . 238.3.6 Security as a Service . . . . . . . . . . . . . . . . . . . . . . . . 248.3.7 Security as Infrastructure . . . . . . . . . . . . . . . . . . . . . . 24

8.4 Standardisierte Sicherheitsmaßnahmen . . . . . . . . . . . . . . . . . . . 258.4.1 XML-Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 258.4.2 WS Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Verzeichnisse iii

8.4.3 Security Assertion Markup Language . . . . . . . . . . . . . . . 268.5 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

LITERATUR 28

Verzeichnisse iv

Abbildungsverzeichnis

1 Vergleich der Architekturen . . . . . . . . . . . . . . . . . . . . . . . . . 42 The Context of IT Investment Projects . . . . . . . . . . . . . . . . . . . 63 QM-Prozessmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 Requirements Management & Development Assurance . . . . . . . . . . 85 SOA-based Business Services and Solutions level . . . . . . . . . . . . . 96 Erfolgreichen Prozess- und Organisationsoptimierung im Unternehmen . 107 Wichtige Eckpunkte der SOA . . . . . . . . . . . . . . . . . . . . . . . . 118 E-Business/Service Providers Infrastructure . . . . . . . . . . . . . . . . 139 Der Zugriff über Services auf Applikationsdomänen . . . . . . . . . . . . 1510 Der Service Kundenmanagement . . . . . . . . . . . . . . . . . . . . . . 1611 Eine XML Bomb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2012 XPath-Injection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2013 Sicherheit auf Transportebene . . . . . . . . . . . . . . . . . . . . . . . 2214 Sicherheit auf Nachrichtenebene . . . . . . . . . . . . . . . . . . . . . . 2215 Security as a Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2 SOA EINLEITUNG 1

1 Thematische Einleitung

1.1 Thematische Gliederung

Im ersten Teil der Diskussion über die serviceorientierte Architektur (SOA) werdenwir uns sehr stark mit der Einführung und den betriebswirtschaftlichen Aspekten rundum die SOA Strategie beschäftigen. Nach der betriebswirtschaftlichen Diskussion wirdein technischer Abschnitt folgen, der abschließend um Empfehlungen aus praktischenErfahrungen und bekannten Missverständnissen ergänzt werden soll.

Der zweite Teil soll ein praxisnahes SOA Beispiel geben. Wir haben uns für dieDeutsche Post entschieden und werden Ziele, Umsetzung und auch den Nutzen der SOAEinführung analysieren.

Sicherheitsaspekte und die sich daraus ergebenen Sicherheitsanforderungen sollenden letzten Teil bilden. Hier werden bekannte Risiken und Bedrohungen sowie Sicher-heitskonzepte und -Maßnahmen genauer erläutert.

1.2 Thematische Abgrenzung

Wir haben für die gesamte Ausarbeitung Schwerpunkte der SOA Thematik ausgewähltund diese intensiv untersucht. Eine Abdeckung aller Themengebiete rund um SOA istan dieser Stelle nicht möglich, da dieses den vorgegebenen Rahmen der Ausarbeitungüberschreiten würde.

2 SOA Einleitung

"Eine service-orientierte Architektur ist einer der

wichtigsten Wegbereiter für das Unternehmen des 21.

Jahrhunderts" [SagSoC]

SOA wird heute als Trend in weltweit agierenden Unternehmen vermarktet und ist amMarkt als solcher akzeptiert. Als erfolgreiches Beispiel soll das SOA Konsortium erwähnt

2 SOA EINLEITUNG 2

werden, das weltweit agierende, SOA unterstützende und betreibende Unternehmen bün-delt und die SOA Strategie und das einheitliche Verständnis über die Thematik weitervorantreibt.

"Um die Vorteile der SOA zu nutzen sind signifikante

Änderungen in der IT und im Business notwendig" [SagSoC]

In dieser Ausarbeitung möchten wir das zentrale Statement herausarbeiten, dass SOAmehr als eine technische Architektur darstellt. Vielmehr handelt es sich um eine Strategiedie signifikante Änderungen am Unternehmen sowohl auf Seite des Business Prozessesals auch auf Seite der technischen Architektur voraussetzt.

3 SITUATIONSANALYSE 3

3 Situationsanalyse

Um den Wechsel der Strategien vor und nach der Zeit um die SOA Einführung zu be-schreiben, sollen zum Einstieg sowohl die bestehende als auch die geplante Architekturauf einem abstrakten Level genauer analysiert und erläutert werden.

3.1 Architektur vor der SOA Einführung

Vor der SOA Einführung wurden in Unternehmen oft separate Datensilos geschaffen, diesich schwer in bestehende Infrastrukturen integrieren ließen. Wenn man diese Datensi-los einmal genauer untersucht, so stellt man fest, dass sie oft sehr schwerfällig und vonanderen Systemen getrennt sind. Die logische Folgerung ist, dass sich die Systeme alssehr unflexibel darstellen und eine Interaktion bzw. Integration nur sehr eingeschränkt er-möglichen. Die eben beschriebenen "Silos" verwalten oft ganze Anwendungen und Datenkompletter Geschäftsprozesse. Eine fehlende Kompatibilität hat zur Folge, dass diese Da-ten bei Bedarf nicht weiter verwendet und somit aufwändig neu angelegt werden müssen.Resultierend war eine aufwändige bzw. teure Pflege. Zusätzlich ergab sich ein komplexerWartungsprozesse der Systeme und deren Informationen.

3.2 Architektur nach der SOA Einführung

Wenn wir über eine Zeit nach der gelungenen Einführung einer SOA Strategie sprechen,so analysieren wir gemeinsam genutzte Services über Systemgrenzen hinaus. DieInstallation dieser Services erlaubt eine Zusammenarbeit bzw. Interaktion verschiedenerDienste untereinander. Auch die Integration bestehender Services in Neuentwicklungenist mit der SOA problemlos möglich.

Folgen der SOA Einführung sind, dass Funktionalitäten bzw. Geschäftsprozesse,die durch einzelne Funktionalitäten abgebildet werden, in Services ausgelagert werden.Diese Services sind in der Regel lose gekoppelt. Nach der Einführung von Services solltezum Beispiel keine manuelle Datenintegration im Backend-Bereich mehr notwendig sein.Information werden von entsprechenden Diensten auf Anfrage zur Verfügung gestellt.Anfragende Komponenten werden in diesem Fall ebenfalls von Services abgebildet.

3 SITUATIONSANALYSE 4

3.3 Vergleich der Architekturen

Ein direkter Vergleich der Architekturen der Vergangenheit und der Zukunft zeigt denWandel von geschlossenen, monolithischen System zu gemeinsam genutzten, kompati-blen und integrierten Services.

Wurden in der Architektur vor der Einführung von SOA Zugriffe auf Informations-quellen bzw. Funktionalitäten separat und für jede Notwenigkeit neu implementiert,so können heute standardisierte Services einmalig implementiert und in der Zukunftwiederholt genutzt werden.

Abbildung 1: Vergleich der ArchitekturenQuelle: www.ibm.com (Juli 2009)

Wieder verwendbare Abbildungen von Geschäftsprozessen erlauben es außerdem, beste-hende Services zu neuen, übergreifenden Services zu kombinieren (siehe Abbildung 1).Die resultierende kurze Implementierungsphase bietet einen erkennbaren Mehrwert fürden Kunden und damit einen Vorteil gegenüber Konkurrenzarchitekturen, die für wieder-holte Kundenanfragen einen großen Aufwand generieren. Zudem zeigt die Abbildung eineklare Trennung in die verschiedenen Service Layer. Mit Hilfe dieser Trennung in Appli-kationsschichten lassen sich einzelne Services ganzer Applikationen leicht austauschen,kosteneffizient erweitern und anpassen.

4 SOA STRATEGIE 5

4 SOA Strategie

Nach der Einführung in die Thematik und der abstrakten Analyse der Architekturen sollendie Ziele der SOA Strategie analysiert werden. Zudem werden sowohl betriebswirtschaft-liche als auch technische Eigenschaften diskutiert.

4.1 Ziele einer SOA Strategie

Ziel einer SOA Strategie ist die Bereitstellung fachlicher Dienste als Services und dieBereitstellung von Funktionalitäten über standardisierte Schnittstellen.

"Die service-orientierte Architektur ist ein

Systemarchitektur-Konzept, das die Bereitstellung

fachlicher Dienste und Funktionalitäten in Form von

Services vorsieht. Ein Service ist in diesem Kontext eine

Funktionalität, die über eine standardisierte Schnittstelle

in Anspruch genommen werden kann." [SOAErNu]

Das SOA einführende Unternehmen untersucht im Rahmen der Einführung interneProzesse und deren Abbildung in der Technologie. Anschließend wird über Anpassungendieser Services die Möglichkeit geschaffen, komplette Business Prozesse über Servicesabzubilden. Vorteile dieser Architektur sind eine leichtere Verständlichkeit der durchkomplexe Technologien umgesetzten Funktionalitäten für nicht Techniker (es handelt sichweiterhin "nur" um einen abstrakten Business Prozess) und eine flexiblere Ausrichtungdes Unternehmens an die Anforderungen des Marktes.

Im Idealfall bildet die SOA komplette Geschäftsprozesse mit Hilfe der IT ab.

4.2 Betriebswirtschaftliche Analyse der SOA Strategie

Nach der Diskussion von Zielen einer SOA gilt es nun die betriebswirtschaftlichen Vor-teile dieser Strategie genauer zu erläutern.

4 SOA STRATEGIE 6

4.2.1 Besserer ROI für bestehende IT-Systeme

Zu Beginn soll der bessere Return on Investment (ROI) für die bestehenden IT Systemeerwähnt werden.

Abbildung 2: The Context of IT Investment ProjectsQuelle: http://www.ctg.albany.edu (Juli 2007)

Abbildung 2 zeigt die Abhängigkeit des ROI von den zugrundeliegenden Projektenaus den Business Prozessen. Aktuelle Erfahrungen zeigen, dass durch die Einführungeiner SOA selten bestehende Anwendungen ersetzt werden. Vielmehr bietet sich dieMöglichkeit Funktionen von Legacy-Programmen durch Transformation in Services indie neu angelegte Architektur zu integrieren und die Lebensdauer der Altsysteme zuerhöhen.

Durch die Integrierung der Alt-Systeme werden somit historische Investitionen geschützt.Zusätzlich ermöglicht eine Integration bestehender Alt-System einen reibungslosenÜbergang zwischen den Architekturgenerationen.

4 SOA STRATEGIE 7

4.2.2 Verbesserte Kundenzufriedenheit

Abbildung 3: QM-ProzessmodellQuelle: http://www.haufe.de (Juli 2009)

Nach heutigen Erfahrungen und statistischen Erhebung ist es für den Kunden immerwichtiger bestehende oder nach Kundenwünschen implementierte Geschäftsprozesse ver-stehen, analysieren und bewerten zu können. Abbildung 3 zeigt die Transformation vonKundenforderung in die zu erbringende Kundenzufriedenheit. Die Abbildung kompletterGeschäftsprozesse durch die IT ermöglicht eine leichtere Kundenanalyse und lässt eineoffene Diskussion über Geschäftsprozesse und deren Implementierung zu. Zusammen mitder Flexibilität der SOA ermöglicht dieses eine schnelle Reaktion auf Kundenbedürfnisseund eine direkte Verbesserung der Kundenzufriedenheit.

4.2.3 Bessere Abstimmung von IT- und Business-Zielen

Wie im vorherigen Kapitel beschrieben liefert eine SOA im Idealfall ein komplettes Ab-bild der gesamten Unternehmensprozesse. Durch die mögliche Abbildung der Schlüs-selprozesse durch visuelle Hilfsmittel (z.B. die formale Methode der Modellierung vonSystemen und deren Prozessen mit Hilfe von Petri-Netzen) wird es den Fachabteilungenund auch dem Kunden ermöglicht umgesetzte Prozesse besser analysieren zu können.Dieses beutet sowohl auf technischer Ebene als auch aus Sicht der Manager eine leichtereUmsetzung der Prozesse (siehe Abbildung 4).

4 SOA STRATEGIE 8

Abbildung 4: Requirements Management & Development Ass-urance

Quelle: http://www.modernanalyst.com (Juli 2009)

Ist eine bessere Verständlichkeit gegeben, so lassen sich Innovationsentscheidungengegenüber Entscheidungsträgern besser argumentieren, was im Endeffekt zu einerSteigerung der Unternehmensdynamik beiträgt. In einer SOA sind die Chancen dasUnternehmen durch Innovationen voranzutreiben in der Regel deutlich erhöht.

Wenn zudem sowohl auf wirtschaftlicher als auch auf technischer Ebene über diegleichen Ziele und mit dem gleichen Verständnis der notwendigen Änderungen gespro-chen wird, ermöglicht dieses eine bessere Abstimmung und Einhaltung der strategischenUnternehmensziele.

4.3 Technische Analyse der SOA Strategie

Nach der Diskussion der betriebswirtschaftlichen Eigenschaft gilt es im nächsten Schrittdie technischen Eigenschaften zu analysieren.

4.3.1 Technische Eigenschaften

Die Einteilung der zu erbringenden Funktionalitäten in Services bietet betriebswirtschaft-liche Vorteile. Aus technischer Sicht fördert diese Einteilung die architektonische Kom-ponierbarkeit separierter Services zu einer Gesamtapplikation.

4 SOA STRATEGIE 9

Abbildung 5: SOA-based Business Services and Solutions levelQuelle: http://www.ibm.com (Juli 2009)

Durch die Verwendung offener Standards wie XML, SOAP oder JMS (siehe Abbildung 5)wird die Möglichkeit der gezielten Wiederverwendung gefördert. Die Verwendung offe-ner Standards erlaubt zudem die unternehmensübergreifende Nutzung entstandener Ser-vices.

4.3.2 Technische Vorteile nach Einführung einer SOA

Zu den technischen Vorteilen nach der Einführung der SOA kann gesagt werden, dassdurch die Einführung von Services eine verbesserte Integration bestehender Lösungen indie neue Architektur möglich ist. Die vereinfachte Integration mindert Kosten und stellteinen Wettbewerbsvorteil gegenüber Mitbewerbern dar. Die Investitionen in eine einheit-liche Kommunikationsstruktur, ebenfalls abgebildet durch bestehende Standards, führendurch die sich erübrigende Diskussion der aufzusetzenden Kommunikationsstruktur zueiner Performanceverbesserung zu Projekt- / Produktionsbeginn.

Services in einer SOA werden über bekannte Schnittstellen sowohl intern als un-ternehmensübergreifend genutzt. Der Vorteil der SOA ist, dass Clients unabhängig vomAufbau bzw. der Realisierung des Services erstellt werden können und sich nur umden Aufruf, die Interaktion mit dem Service kümmern müssen. Wichtig ist "nur" dieEinhaltung der Definition der Schnittstelle. Beim Aufruf bestehender SOA Servicesspricht man daher von dem Aufruf einer Blackbox.

5 ERKENNTNISSE DER SOA STRATEGIE 10

Abbildung 6: Erfolgreichen Prozess- und Organisationsoptimie-rung im Unternehmen

Quelle: http://www.trigonum.de (November 2008)

Auf Kostenseite erlauben standardisierte Schnittstellen bzw. festgelegte architektonischeRichtlinien schnelle und kostengünstige Entwicklungen. Zusammen mit der erhöhten Ver-ständlichkeit der zu erbringenden Lösung und der flexiblen (IT)-Prozessstrukturen ergibtsich ein Argumentationsvorteil in der Diskussion um eine SOA Einführung. Flexible undimmer wieder angepasste (Geschäfts-) Prozesse bieten die Möglichkeit einen kontinuier-lichen Verbesserungsprozess (siehe Abbildung 6) dauerhaft zu implementieren.

5 Erkenntnisse der SOA Strategie

Nach der betriebswirtschaftlichen und technischen Analyse der SOA wollen wir uns mitder Praxis beschäftigen und bekannte Probleme der SOA Einführung und entstandenenMissverständnissen genauer erläutern.

5.1 Bekannte Probleme bei der Einführung einer SOA

In den letzten Jahren ist SOA zu einem Schlagwort in Unternehmensstrategie(n) gewor-den. Bei der Einführung der SOA haben sich allerdings immer wieder Probleme ergeben(siehe Abbildung 7), die an dieser Stelle diskutiert werden sollen.


Abbildung 7: Wichtige Eckpunkte der SOAQuelle: http://www.ap-verlag.de (Juli 2009)

Ein häufig auftretendes Problem ist, dass die neu eingeführte Strategie immer nur solange auf bekannten Standards aufsetzt, bis die Architektur an unternehmensspezifischeGrenzen stößt. Wenn man an dieser Stelle den standardisierten Weg verlässt und unter-nehmensspezifische Anpassungen implementiert muss jeden Unternehmen bewusst sein,dass ein Großteil der Vorteile der SOA (z.B. unternehmensübergreifende Verwendung)nicht mehr genutzt werden kann. Lassen sich SOA Standards im Unternehmen nichtanwenden, so deutet dieses oft auf falsch definierte Prozesse hin. An dieser Stellesollten zuerst bestehende Prozesse genauer analysiert werden, bevor über die strategischeEntscheidung der unternehmensspezifischen Anpassung der SOA nachgedacht wird.

Ein weiteres Problem ergibt sich in der Planung einer SOA Einführung. In dieserPlanung wird oft ein hoher Aufwand in die technische Gestaltung der neuen Architekturgesteckt. Die Migration der Bestandsdaten bzw. bestehender Altsysteme wird vernachläs-sigt, so dass es bei der Einführung zu Problemen kommt. Diese Probleme können durcheine intensivere Situationsanalyse vermieden werden.

Werden heute vornehmlich die technischen Vorteile der Architektur gesehen, soversäumt man in der Planung häufig die Anforderungen der SOA an Performance undSecurity zu berücksichtigen. Probleme ergeben sich in der Regel nicht auf den erstenBlick. Erst eine langfristige Analyse deckt schwächen der Umgebung auf. An dieserStelle sollte auf Erfahrungen von Partnerunternehmen oder auf Fachpublikationenzurückgegriffen werden. Eine nachträgliche Änderung der Umgebung kann für einUnternehmen sehr aufwändig und kostenintensiv werden.


Erfahrungen haben gezeigt, dass durch eine intensive Planung zur Einführung derSOA die meisten (bekannten) Probleme vermieden werden können. Ein Unternehmensollte gerade beim Thema SOA lieber möglichst viel Zeit in die Planung investieren alsspäter über Monate die eingeführte Lösung auf Schwachstellen und Fehler zu analysieren.

5.2 Bekannte Missverständnisse zum Thema SOA

Während den letzten Jahren halten sich in der Wirtschaft immer mehr Missverständnis-se zum Thema SOA. Die zum Verständnis wichtigsten sollen an dieser Stelle genauerbeleuchtet werden:

5.2.1 "Wenn du SOA einführst, sind alle deine Komponenten automatisch kompa-tibel zu einander" [SoaThe]

Laut Definition sind in einer SOA alle Komponenten kompatibel zu einander. Dieses be-deutet allerdings nicht, dass durch die Einführung von SOA alte, bestehende Kompo-nenten problemlos kompatibel zu Neuentwicklungen nach SOA sind. Um dieses zu ge-währleisten müssen die betroffenen Funktionalitäten und Schnittstellen der Alt-Systemeanalysiert und in die SOA, also in Services transformiert werden.

5.2.2 "Wenn du Web Services verstehst, hast du keine Probleme eine SOA aufzu-bauen." [SoaThe]

Sehr große und intensive Diskussionen gibt es immer wieder um Web Services und denZusammenhang zur SOA. Wer in der heutigen Zeit mit WS arbeitet hat mit Sicherheiteinen großen Vorteil gegenüber den Unternehmen, in denen dieses Know-how fehlt. WSbeschreiben allerdings nur einen kleinen, wenn auch wichtigen Teil der SOA. Wichtigist, dass ein Verständnis dafür besteht, wie die Business Prozesse mit der Applikations-logik zusammen arbeiten und wie dieses bestmöglich in die SOA integriert werden kann.SOA erfordert somit weit mehr als "nur" WS Know-how. Es geht darum ein Verständnisfür das Geschäft und die IT aufzubauen. Zusätzlich ist das Know-how über die Verknüp-fungsmöglichkeiten dieser Themengebiete zwingend erforderlich.

6 SOA UND DER BEZUG ZU E-BUSINESS 13

5.2.3 "SOA löst fachliche Probleme" [SoaThe]

Das wohl größte Missverständnis ist, dass SOA fachliche Probleme löst. Durch SOA al-leine können keine fachlichen Probleme gelöst werden. SOA soll vielmehr als ein Denk-anstoß gesehen werden, um fachlichen Prozesse zu überdenken und in Richtung SOAaufzustellen. In diesem Veränderungsprozess können bestehende Probleme in den Busi-ness Prozessen behoben werden.

6 SOA und der Bezug zu E-Business

"E-Business ist die integrierte Ausführung aller

automatisierbaren Geschäftsprozesse eines Unternehmens mit

Hilfe von Informations- und Kommunikationstechnologie."

[DeEbWi]

Bei der SOA Strategie sprechen wir davon, einzelne Geschäftsprozesse in spezielle Ser-vices auszulagern und von einander lose zu koppeln. Wirtschaftlich versucht die SOAGeschäftsprozesse zu optimieren und diese aus technischer Sicht optimal in die Umge-bungsarchitektur zu integrieren.

Abbildung 8: E-Business/Service Providers InfrastructureQuelle: http://www.advantech.com.tw (Juli 2009)

Wenn wir diese Zielsetzung mit der Definition von E-Business vergleichen, so ist dieSOA optimal für den Einsatz im E-Business geeignet, da die Anforderungen (siehe Ab-bildung 8) des E-Business optimal umgesetzt werden können. Über die SOA lässt sichein E-Business sehr gut konzipieren, betreiben, verwalten und gegebenenfalls gegen neueAnforderungen erweitern.

7 UNTERNEHMEN UND DEREN SOA EINSATZ 14

7 Unternehmen und deren SOA Einsatz

7.1 Deutsche Post Brief

Die Deutsche Post Brief ist der größte Unternehmensbereich der Deutschen Post WorldNet und größter Briefdienstleister in Europa. Das folgende praxisnahe SOA Beispiel[SOAPuP] verdeutlicht, wie die Deutsche Post Brief ihre SOA entwickelt hat und zeigtdabei die Ziele, Umsetzung sowie den Nutzen dieser Einführung.

7.2 Gründe

Die IS-Architektur der Deutschen Post Brief wurde mit Blick auf die Vergangenheit nichtzentral geplant. Das führte dazu, dass Kerninformationen wie Kundendaten, Kosten oderInformationen über den Wettbewerb nicht von jedem System gleichermaßen verarbeitetwerden konnten und daher jedes Teilsystem über einen eigenen Datenbestand verfügte.Ein weiterer entscheidender Faktor war die immer komplexer werdende Anzahl vonIT-Projekten. Diese Schlüsselfaktoren führten dazu, dass neue Geschäftsanforderungenzunehmend seltener in dem gewünschten zeitlichen Rahmen umgesetzt werden konnten.

Eine mangelnde projektübergreifende Koordination und Planung sorgte des Weiteren füreine große Anzahl von spezialisierten sowie in sich geschlossenen Anwendungssyste-men. Die Folge waren redundante Funktionen in Anwendungen sowie eine mehrfacheDatenhaltung geschäftsspezifischer Informationen. Heterogene, schlecht dokumentierteSchnittstellen einzelner Anwendungen, deren Abhängigkeiten nicht nachvollzogenwerden konnten, führten zu einem enormen Anpassungsaufwand und geringer Wieder-verwendung bei neuen Projekten. Zu guter Letzt stiegen die Investitionen in die Wartung/Bertrieb der historisch gewachsenen IS-Architektur und IT-Infrastruktur, wodurch nichtmehr ausreichend IT-Budget für die Neu-/ Weiterentwicklung der bestehenden Systemezur vorhanden war.

7.3 Ziele

Das aus den oben genannten Gründen abgeleitete Ziel der Deutschen Post Brief war ei-ne zentral gesteuerte und geschäftsorientierte Applikationsarchitektur. Dabei sollte die


Applikationsarchitektur als eine Richtlinie zum Entwickeln von redundanzfreien Anwen-dungen hinsichtlich der Implementierung, Funktionalität und Datenhaltung dienen. DieErwartung war eine bessere Wiederverwendbarkeit aller Funktionen zur Unterstützungneuer Prozesse und die Möglichkeit gezielt und isoliert neue Funktionen zu implemen-tieren. Das Ergebnis aller Anforderungen war eine fachliche SOA, in denen voneinanderisolierte Anwendungsdomänen und Schnittstellen die den Zugriff auf sämtliche Funktio-nen und Daten in diesen Domänen bereitstellen zum Einsatz kommen.

7.4 Umsetzung

Nach der Identifizierung der Kern-Geschäftsprozesse wurde aufbauend auf dieser Analyseeine fachliche Applikationsarchitektur entwickelt. In dieser wurde die fachliche Funktio-nalität sowie die Daten prozessunabhängig und ohne Redundanzen in die jeweiligen Ap-plikationsdomänen abgebildet. Abbildung 9 illustriert das vorgehen. Dabei finden sämt-liche Zugriffe auf die jeweiligen Domänen über spezielle Serviceschnittstellen statt, diejeweils in der Lage sind mehrere Operationen auszuführen. Alle Services wurden objek-torientiert nach den Geschäftsobjekten Kunde, Rechnung, oder Vertrag abgebildet undstellen Funktionen wie z.B. anlegen, suchen oder löschen bereit.

Abbildung 9: Der Zugriff über Services auf Applikationsdomä-nen

Quelle: [SOAPuP]

Die Umstellung der Applikationslandschaft auf die SOA soll anhand des Service Kun-denmanagement - siehe dazu auch Abbildung 10 - vorgestellt werden. Der Service stellt


u.a. den Call-Center- oder CRM-Systemen Operationen wie seek, get, create, update,delete, getChildNodes und checkAdress bereit. Damit haben die Nutzer die Möglichkeitsämtliche Kundendaten zentral zu erfassen und zu verwalten.

Die Menge an unterschiedlichen Anwendungen und ihrer lokalen Datenhaltung wurde zueiner zentralen Stammdatenbank migriert. Die bereits bestehenden Anwendungen sowiedie neu implementierten verwenden diese Datenbank über die Serviceschnittstellen.Mobile Anwendungen, die nicht über einen dauerhaften Online-Zugang verfügen,speichern und arbeiten weiterhin mit lokalen Daten, welche aber regelmäßig mit derzentralen Datenbank synchronisiert werden.

Abbildung 10: Der Service KundenmanagementQuelle: [SOAPuP]

7.5 Nutzen

Nach der erfolgreichen Umsetzung der Service Oriented Architecture identifizierte dieDeutsche Post Brief folgenden Nutzen durch die Umstellung.

7.5.1 Wiederverwendung von Services und Vermeidung redundanter Softwareent-wicklung

Die Services werden im Schnitt zwei- bis dreimal von unterschiedlichen Systemen wie-derverwendet. Auf Grund der Wiederverwendung und systemweiten Harmonisierung


führte zu einer Reduzierung von Redundanzen und somit zu einer optimierten Daten-konsistenz.

7.5.2 Kürzere Projektlaufzeiten und schneller Time-To-Market

Die Entwicklung neuer Anwendungen lässt sich mittels der Wiederverwendung vorhan-dener Services von vielen Monaten auf einige Tage bzw. Wochen verringern.

7.5.3 Niedrigere Wartungskosten

Die Komplexität und Redundanzen der Applikationsarchitektur verringerten sich durchden Einsatz und die Bildung von Anwendungsdomänen sowie die bessere Kontrolle derServiceschnittstellen. Das wirkte sich positiv auf die Kostenstruktur zur Wartung und Be-trieb der IS-Architektur aus, wodurch ca. 7% mehr IT-Budget für die Entwicklung neuerAnwendungen zur Verfügung stehen.

7.5.4 Bessere Reaktionsfähigkeit auf neue Geschäftsanforderungen

Mit der Entwicklung einer Domänen- und Servicearchitektur schaffte die Deutsche PostBrief einen Vermittler zwischen der Prozess- und der Applikationsarchitektur. Dabei wer-den alle Daten und Funktionen der Applikationsarchitektur von einer technischen in einefachliche Sicht übersetzt, wodurch sich die Kommunikation zwischen dem Fachbereichund dem IT-Bereich deutlich verbessert. Des Weiteren erhält der Fachbereich damit mehrVerantwortung, da dieser nun auch für Daten und Services einzelner Anwendungsdomä-nen zuständig ist.

8 SOA & SICHERHEIT 18

8 SOA & Sicherheit

8.1 Anforderungen

8.1.1 Authentifizierung

Soll die Verifikation einer Identität in einem System sicherstellen. Dabei kann es sichum eine Person, ein Gerät oder einen anderen Service handeln. Mittels der Authentifi-zierung kann kontrolliert werden, wer oder was einen bestimmten Service aufruft. In derRegel sollten Sicherheitsfunktionen wie eine Public Key Infrastructure, in der Zertifikateverwendet werden, zum Einsatz kommen. Damit können weitere Anforderungen wie dieIntegrität und Vertraulichkeit sichergestellt werden.

8.1.2 Autorisierung

Dient der Prüfung, ob eine bestimmte Identität Zugriff auf eine Ressource erhalten darf.Dabei handelt es sich z.B. um eine Kontrollfunktion, ob ein bestimmter Service aufge-rufen werden darf. In der Regel wird in diesem Kontext das Rollenkonzept verwendet.Darin werden Benutzer bestimmten Rollen und Gruppen zugewiesen, die dann mit Rech-ten ausgestattet sind.

8.1.3 Vertraulichkeit/ Privatsphäre

Der Transport der Daten muss vertraulich behandelt werden. Das bedeutet, dass ein nichtautorisierter Zugriff auf die Daten in jedem Fall verhindert werden muss. Nur autorisierteund authentifizierte Identitäten dürfen auch Zugriff auf die Daten erhalten. Die Vertrau-lichkeit umfasst das Lesen, Verändern und Löschen von Daten und kann mittels krypto-grafischer Verfahren gewährleistet werden.

8.1.4 Integrität

Integrität wird in Datenintegrität und Herkunftsintegrität unterteilt. Die Datenintegritätsoll sicherstellen, dass die Daten während der gesamten Übertragung nicht manipuliert


werden. Die Herkunftsintegrität hingegen ist für die korrekten Absenderdaten verantwort-lich. Das beinhaltet, dass der Absender die Daten vertrauensgemäß hinterlegt hat und dassdiese während der Übertragung nicht verändert worden sind.

8.1.5 Verfügbarkeit

Das System muss resistent gegenüber Angriffen sein, die versuchen das System so zuüberlasten, dass es nicht mehr reagieren kann und nicht erreichbar ist. Des Weiteren mussdas System für alle autorisierten Identitäten zu jeder Zeit zugänglich sein, so dass dieseZugriff auf ihre gewährten Informationen und Ressourcen haben. Ein Single-Point-of-Failure sollte daher in jedem Fall vermieden und auf eine lose Kopplung aller Komponen-ten geachtet werden.

8.2 Risiken & Bedrohungen

8.2.1 Replay Attacks

Das erneute Senden einer bereits gesendeten Nachricht. Ein System merkt sich nicht,welche Nachrichten bereits bearbeitet wurden. Eine Replay Attacke kann wie folgt be-schrieben durchgeführt werden. Ein Angreifer fängt eine Nachricht auf dem Weg zur Ver-sandabteilung ab. Er sendet diese Nachricht zu einem späteren Zeitpunkt erneut an dasSystem. Da das System nicht erkennt, dass die Nachricht bereits verarbeitet wurde, kannz.B. ein kostenpflichtiger externer Service mehrmals aufgerufen werden. Handelt es sichbei dem externen Service z.B. um eine Kreditkartenvalidierung, würde für das angegrif-fene Unternehmen dadurch Kosten entstehen.

8.2.2 XML Spezifische Angriffe

XML-Bombs XML-Bombs sind endlose Rekursionen innerhalb von XML-Dokumenten.Dabei wird Die XML Funktion DOCTYPE ausgenutzt, die zur Definition von Entitätenverwendet, die als Platzhalter dienen. Das folgende Beispiel illustriert die Funktionsweise.


Abbildung 11: Eine XML Bomb

Um das Beispiel zu erläutern, fangen wir am Ende an. Dem Entity /d/ wird der Werte wowzugewiesen. In der Zeile darüber wird dem Entity /c/ drei Mal das Entity /d/ zugewiesen.Das bedeutet, dass /c/ drei mal den Wert von /d/ beinhaltet. In der darüber liegenden Zeilewird dem Entity /b/ drei Mal der Wert von /c/ zugewiesen und letztendlich erhält dasEntity /a/ drei Mal den Wert von /b/. Wird nun einmal das Entity /a/ aufgerufen erhaltenwir eine Ausgabe, in der 27 Mal der Wert w ausgegeben wird.

XPath-Injection XPath-Injection kann das Verhalten der Anwendung ändern, indem inPlatzhaltern für Daten (Variablen) ein spezielles Code-Stück platziert wird. Es ist auchals SQL-Injektion für Datenbankabfragen bekannt. Das folgende Beispiel illustriert dieFunktionsweise.

Abbildung 12: XPath-Injection


Die obere Maske lässt Eingaben für den Benutzer und sein Passwort zu. Wird für dieVariable /user/ der String ’user’ und für die Variable /passwort/ der String ’or ’1’=’1’eingetragen, liefert die Ergebnismenge alle Benutzer des Systems, denn 1=1 ist immerWahr. Das funktioniert aber nur dann, wenn die Spalte der Benutzer in der Datenbankauch ’user’ lautet.

8.2.3 WSDL- und Service Scanning

Details und Parameter eines Web-Service sind öffentlich zugänglich. Damit stehen ausrei-chend Informationen zur Verfügung, die verwendet werden können. Mittels einer Softwa-reanalyse kann ein Angriff den Dienst auf Schwachstellen untersuchen und damit weitereAngriffsmöglichkeiten entdecken.

8.2.4 Kompromittierung eines Service

Services sind in der Regel (öffentlich) verteilt - wenn die SOA externe Services berück-sichtigt. Durch manipulieren eines Service oder platzieren eines ’schlechten’ Service imRepository können andere Services bzw. Geschäftsprozesse beeinflusst werden.

8.2.5 Unberechtigte Servicenutzung

Möglichkeiten dürfen nie ausgeschlossen werden, die es erlauben, dass ein nicht kor-rekt autorisierter Nutzer Zugriff auf einen Teil des Geschäftsprozesses bzw. auf einenoder mehrere Services erhält. Das muss administrativ (z.B. durch Security Policies) striktüberprüft und unterbunden werden.

8.3 Konzepte

8.3.1 Sicherheit auf Transportebene

Die Absicherung der Protokolle kann mittels SSL/ TLS verschlüsselt und damit geschütztwerden. Statt z.B. HTTP wird dann HTTPS verwendet. In diesem Fall spricht man vonSicherheit auf Transportebene. Hierbei handelt es sich allerdings nur um eine Punkt zuPunkt Verschlüsselung zwischen zwei Systemen. Das bedeutet, dass die Daten nur auf


dem Transportweg geschützt und keine Ende-zu-Ende Verschlüsselung von Absender zuEmpfänger über mehrere Host vorhanden ist. Systeme welche die Daten weiterleiten ha-ben somit Zugriff auf die Daten, da die Daten selber nicht verschlüsselt sind.

Abbildung 13: Sicherheit auf TransportebeneQuelle: [BSI]

8.3.2 Sicherheit auf Nachrichtenebene

Da bei einer SOA aber Nachrichten-basierte Systeme eingesetzt werden, die offene, ein-fach zu lesende Standards (XML) verwenden, muss die Integrität der Daten auf Nachrich-tenebene sichergestellt werden. Hierbei wird nicht nur der eigentliche Übertragungsweggeschützt, sondern ebenfalls eine Änderung an der Nachricht selbst vorgenommen. Beieiner SOA ist zudem wichtig, dass eine Nachricht nicht immer vollständig, sondern nurTeile von ihr geschützt werden. Gründe dafür sind zum einen die Geschwindigkeit zumÜbermitteln der Nachricht, zum anderen der Gesamtprozess der Übermittlung. Im zwei-ten Fall kommt es in der Regel vor, dass ein Empfänger eine Nachricht weiterverarbeitenmuss und diese anschließend weiterleitet, aber nicht den Inhalt der gesamten Nachrichtlesen darf. Ein Beispiel wäre eine Bestellung, in der unterschiedliche Daten des Kundenvorhanden sind. Die Bestellung durchläuft unterschiedliche Empfänger (Stationen, Pro-zesse), die nur Zugriff auf die für sie bestimmten Informationen erhalten dürfen.

Abbildung 14: Sicherheit auf NachrichtenebeneQuelle: [BSI]

Im einfachsten Fall werden die Daten vom Sender anhand eines kryptografischen Verfah-rens verschlüsselt, bevor dieser die Daten zum Empfänger sendet. Die Daten werden indiesem Zustand durch alle dazwischen liegende Systeme übertragen. Nur der Empfänger


der Daten kann diese am Ende entschlüsseln. Man spricht daher auch von einer Ende-zu-Ende Sicherheit. Nur der Payload (Nutzdaten) werden i.d.R. verschlüsselt. Die Daten diefür den Transport notwendig sind, befinden sich in einem separaten Header.

8.3.3 XML-Firewalls/ XML-Gateways

XML-Firewalls/ Gateways blocken invalide bzw. schädliche XML Dokumente. Dafürexistieren unterschiedliche Möglichkeiten, wie und wo die Firewall bzw. das Gatewayplatziert wird. Zentrale Firewall, die alle eingehenden Dokumente prüft bietet keine Ende-zu-Ende Sicherheit, sondern nur Punkt-zu-Punkt. Eine andere Möglichkeit besteht dar-in, denzentrale Firewalls einzusetzen. Dabei wird vor jedem Webservice wird eine Fire-wall geschaltet. Dies ist allerdings sehr kostenintensiv und schwer zu verwalten. XML-Gateways können im Gegensatz zu Firewalls auch Transformationen an den Dokumentenvornehmen. Die Dokumente müssen immer für Firewall/ Gateway verschlüsselt werden,da sonst die XML-Validierung fehlschlägt. Das liegt daran, dass die Firewall/ Gatewaynicht in ein verschlüsseltes Dokument hineinschauen kann. Das kann zu Problemen füh-ren, wenn das XML-Dokument an einen inneren Geschäftsprozess gerichtet ist.

8.3.4 Sicherheit auf Fachlicher Ebene

Die Sicherheit wird in die fachlichen Schnittstellen der Services implementiert. Es wer-den z.B. eigene Sicherheitstoken entwickelt, die dann untereinander ausgetauscht werden.Eine weitere Möglichkeit besteht darin, dass die Verschlüsselung bzw. Entschlüsselungselber definiert wird. Diese Formate müssen dann Bestandteil des Service-Vertrags sein.

8.3.5 Applikationssicherheit

Die Anwendungslogik wird von der Sicherheitslogik getrennt. Die Sicherheitsanforde-rungen einer Anwendung müssen bereits vor der eigentlichen Entwicklung erfasst undkoordiniert werden. Werden die Sicherheitsmaßnahmen erst nachträglich implementiert,wird es wesentlich teurer und der Schutz ist im Vergleich zur Implementierung der Si-cherheit während des Entwicklungsprozess der Anwendung niemals so hoch und sicher.Sicherheit muss aus diesem Grund ein wesentlicher Bestandteil des gesamten Lebenszy-klus einer Anwendung sein.


8.3.6 Security as a Service

Innerhalb einer SOA Architektur wird auch der Anspruch erhoben, die Sicherheit von derAnwendungslogik zu trennen und somit als einen eigenen wieder verwendbaren Servicebereitzustellen. Der Begriff Security as a Service verkörpert dabei Sicherheitsmethoden,die als Dienst mittels standardisierte Schnittstellen zur Verfügung gestellt werden undvon allen Anwendungen bzw. Komponenten gleichermaßen verwendet werden können.Die Wiederverwendbarkeit eines solchen Konzepts steht dabei besonders im Mittelpunkt,da die Sicherheitsmethoden von unterschiedlichen Anwendungen gleichermaßen genutztwerden können. Eine Methode von Security as a Service ist die Authentifizierung undAutorisierung von Entitäten. Dabei handelt es sich um ein zentrales System, i.d.R. einenso genannten Identitätsanbieter. Dieser verwaltet die Entitäten mit ihren zugehörigen Rol-len und Profilen und gewährt ihnen von zentraler Stelle aus den Zugriff auf Dienste undRessourcen.

Abbildung 15: Security as a ServiceQuelle: www.soa-know-how.de (Juli 2009)

8.3.7 Security as Infrastructure

Security as Infrastructure wird dann eingesetzt, wenn die Sicherheits und von Anwen-dungslogik getrennt werden soll. In der Regel werden Systeme während der Kommuni-kation von speziellen Komponenten (Appliances oder Proxys) geschützt. Ein Proxy dientdabei als eine Art Vermittler, der zwischen den Anwendungen und Netzwerken und deneigentlichen Systemen (Services) steht. Proxies sind in der Lage Informationen innerhalb


der Nachrichten zu kontrollieren, bzw. zu platzieren oder auszulesen, da sie unmittelbarzwischen den jeweiligen Hosts agieren.

8.4 Standardisierte Sicherheitsmaßnahmen

8.4.1 XML-Security

XML Encryption

Dabei handelt es sich um die Verschlüsselung von XML Dokumenten. Dabei kann das ge-samte Dokument, oder nur Teile verschlüsselt werden z.B. ’nur die Kredikartennummer’oder ’alles außer dem Benutzernamen’.

XML-Signatur

Wird für das digitale Signieren von XML Dokumenten verwendet und dient dem Sicher-stellen der Integrität und Authentizität der Daten.

XML Key Management (XKMS)

Wird für die Verwaltung der Schlüssel/ Zertifikate bei der XML-Signatur verwendet.

8.4.2 WS Security

Ist ein Standard für die Authorisierung und Integrität von Web-Services und dem Proto-koll SOAP. Es handelt sich dabei um Verfahren für die Integration von Token, Schlüssel,Signaturen in eine SOAP-Nachricht.

WS Trust

Ist ein Standard für das Ausstellen, Erneuern und Validieren von Sicherheitstoken. Dientzur Etablierung, Vermittlung und Beurteilung sicherer Beziehungen.

WS Security-Policy

Ermöglicht das Herausfinden, welcher Service-Anbieter welchen Sicherheitsstandard un-terstützt bzw. erwartet.

WS SecureConversation


Dient zum Etablieren eines gemeinsamen Sicherheitskontext für den Austausch mehrererNachrichten. Damit sollen Anfragen zu einer Session an einen Identitätsanbieter reduziertwerden.

WS Federation

Definiert Mechanismen für die Integration und den Zusammenschluss unterschiedlicherSicherheitsbereiche durch gegenseitigen Austausch von Identitäten, Attributen und Au-thentifizierungen.

8.4.3 Security Assertion Markup Language

Wird verwendet um erweiterte Sicherheitsinformationen in SOAP-Dokumente zu inte-grieren. Dabei wird auf ein beliebiges "Subject" bezug genommen, z.B. einen ServiceConsumer der einen Web-Service aufruft. Diese Subects werden als Assertions integriert.Assertions definieren drei zusätzliche Einträge um Eigenschaften zu definieren.

Attribute Statement

Damit können vertrauenswürdige Aussagen über beliebige Attribute eines Subjects z.B.einer Email Adresse gemacht werden.

Authentication Decision Statement

Entscheidung ob ein Subject autorisiert ist auf eine Ressource zuzugreifen wird in dieNachricht integriert

Authentication Statement

Erweiterte Authentifizierungsinformationen können damit in eine SOAP-Nachricht ein-gebunden werden, z.B. ein Zertifikat etc.

8.5 Fazit

Innerhalb von SOA-Infrastrukturen kommen überlicherweise dieselben Sicherheitsaspek-te und Mechanismen zum Einsatz, wie sie aus dem Bereich der verteilten Systeme bekanntsind. Zusätzlich zu diesen Konzepten müssen bei einer SOA weitere Dinge beachtet wer-den. [SOAidP]


• Innerhalb einer SOA arbeiten viele (fremde) Systeme miteinander zusammen, wasdie Verwendung von Standard Sicherheitskonzepten stark reduziert.

• Dabei müssen die jeweiligen heterogenen Sicherheitskonzepte der Systeme berück-sichtigt werden.

• Durch den Einsatz von verteilten Systemen, bei denen die Nachrichten über unter-schiedliche Systeme übertragen und dabei von verschiedenen Services aufgerufenwerden, reicht eine Punkt zu Punkt Sicherheit nicht mehr aus.

• Die Daten müssen auf Nachrichtenebene geschützt werden, was dadurch zu einerEnde zu Ende Sicherheit führt.

• Innerhalb einer SOA greifen die unterschiedlichsten Entitäten auf Services und Res-sourcen zu. Daher müssen die Sicherheitsprüfungen zur Laufzeit stattfinden.

Abschließend sollten Sicherheitskonzepte als Service (Security as a Service) bereitgestelltwerden um einen einheitlichen Ansatz zu definieren. Auf diesen sollte die gesamte Ar-chitektur aufbauen, damit alle Anwendungen und Komponenten darauf zentral zugreifenkönnen.

LITERATUR 28

LITERATUR

[SoRzOs] Roger Zacharias. Serviceorientierung: Der OO-König ist tot, es lebe der SOA

König!, OBJEKTspektrum, April 2005

[SoaThe] Thomas Erl. Service-Oriented Architecture: Concepts, Technology, and Design,Indiana: Prentice Hall International, 2006

[SagSoC] Service Oriented Architecture (SOA) advocacy group. SOA Consortium

http://www.soa-consortium.org, 2009.

[SOAErNu] SOA erfolgreich nutzen, JavaSPEKTRUM, März 2006

[DeEbWi] Wikipedia. Definition E-Business http://de.wikipedia.org/wiki/E-Business, Ju-li 2007.

[SOAPuP] Roger Heutschi. Serviceorientierte Architektur (Business Engineering), Ber-lin: Springer, 2007

[BSI] Bundesamt für Sicherheit in der Informationstechnik. Sicher-

heitskompendium für Service-orientierte Architekturen (SOA)

http://www.bsi.bund.de/literat/studien/soa/SOA-Security-Kompendium.pdf,2009.

[SOAidP] Nicolai Josuttis. SOA in der Praxis: System-Design für verteilte Geschäftspro-

zesse, Heidelberg: Dpunkt Verlag, 2008

Service Oriented Architecture

Documents

Transcript of Service Oriented Architecture