Die Einführung von SOA und Composite Applications stellt ganz neue Anforderungen an das Identity- und Access-Management, sowie an die Security von Applikationen und Web Services.

1. DEVELOPERWORLDDEVELOPERWORLD
D
as Ziel einer Service-orientierten Ar-
chitektur (SOA) ist die Implementie-
rung von wieder verwendbaren, auf
modernen Standards basierenden Services
wie etwa Web Services. Diese Services wer-
den mit Hilfe von Business-Prozessen zu
neuenCompositeApplicationsorchestriert.
Solche Services werden von verschiedenen
Applikationen verwendet.
Bei herkömmlichen Applikationen
wurde in der Regel die Einstiegsseite durch
Username und Passwort geschützt. Die Zu-
griffsrechte wurden innerhalb der Applika-
tion geprüft und verwaltet. Mit SOA ist
dieses Modell nicht mehr gut genug. Die
Services müssen die Zugriffsrechte meist
selbst prüfen. So ist sichergestellt, dass die
Services nur von autorisierten Benutzern
aufgerufen werden. Gegebenenfalls kann
das Recht für einen Benutzer auf einem
Service unterschiedlich sein, abhängig von
welcher Applikation er kommt. Dies be-
dingt, dass alle Benutzer zentral authenti-
siert werden und dass die Services jeden
Benutzer eindeutig identifizieren. Damit
aber eine Lösung administrierbar bleibt,
können die Zugriffsrechte für die Benutzer
nicht einfach in den einzelnen Service ab-
Sichere Composite
Applications auf SOA-Basis
Die Einführung von SOA und Composite Applications stellt ganz neue Anforderungen an
das Identity- und Access-Management, sowie an die Security von Applikationen und
Web Services. VON PETER AFFOLTER
Peter Affolter ist Elektro- und Softwareingenieur und
ist seit Februar 2006 als Softwarearchitekt bei Sun
Microsystems (Schweiz) tätig.Grafik1: Die Stufen der Service-orientierten Architektur.
gelegt werden. Darum muss nicht nur die
Authentisierung, sondern auch die Autori-
sierung zentral erfolgen.
Implementierung einer SOA
DerwichtigsteErfolgsfaktorbeiderEinfüh-
rungeinerSOAistdieImplementierungder
klar definierten Layer, die auf offenen Stan-
dards und Technologien beruhen. (siehe
Grafik 1)
DieTechnicalServicessindDienste,wel-
chevonderITentwickeltunddefiniertwer-
den. Sie sind meist sehr fein-granular und
widerspiegeln die einzelnen Funktionalitä-
ten der Backend-Systeme. Dabei können
Aufruf-Charakteristiken wie Synchron/
Asynchron,TransaktionalundLongrunning
eine Rolle spielen. Diese technischen
DienstewerdenmitBPEL(BusinessProcess
Execution Language) zu Business Services
orchestriert oder noch herkömmlich pro-
grammiert.
BereitszudiesemZeitpunktmüssenVer-
treter der Business-Anwendungen einbezo-
gen werden. Nur so lassen sich die Dienste
und deren Granularität so definieren, dass
sie von den Business-Analysten auch ver-
wendet werden können. Die Business-Ser-
vices sollten unabhängig von den Aufruf-
Parametern der unterliegenden Dienste
sein. Nur so lassen sie sich problemlos in
Business-Prozesse integrieren. Sun Micro-
systems verfolgt dabei den Ansatz einer
pragmatischen SOA. Dabei müssen nicht
alle Dienste zum Voraus definiert werden.
Sie können nach Bedarf durch Adaptoren
oder einfache Wrapper erstellt werden.
Auch müssen Dienste nicht immer neu ent-
wickelt werden. Sie lassen sich zum gröss-
ten Teil konfigurieren, indem man vorhan-
dene Adaptoren benutzt.
Unter einer Composite Application
versteht man also eine neue Applikation,
welche SOA-basierende, bestehende Appli-
kationen und Dienste nutzt, um schnell
neuen Business-Anforderungen gerecht zu
werden. Solche Composite Applications
werden, dank dem neuen Standard «Java
BusinessIntegration(JSR2008)»,weiteran
Bedeutung gewinnen und so auch die
Service-orientierte Architektur weiter
verbreiten. (Grafik 2)
JavaBusinessIntegration(JBI)definiert
eine offene und pluggable Architektur für
Integrationen und SOA. JBI erlaubt es, mit
Hilfeeines«CompositeServiceDescriptor»,
eine Composite Application mit einem ein-
zigen Dokument zu beschreiben. So kann
sie, je nach Bedürfnissen, auf unterschied-
lichen Plattformen ausgeführt werden.
Sicher Composite Applications
Um Composite Applications sicher zu ma-
chen reicht es nicht mehr, nur die URL der
Applikation zu schützen und die Zugriffs-
rechte innerhalb dieser Anwendung abzu-
legen und zu prüfen. Da einzelne Services
vonverschiedenenCompositeApplications
aufgerufen werden können, müssen die
Zugriffe und entsprechenden Rechte zen-
44 WWW.COMPUTERWORLD.CH / 15. SEPTEMBER 2006

2. Grafik 3: Der Aufbau von Java Business Integration.
tral abgelegt werden. Wichtig dabei ist ein
zentraler Access Manager, welcher die ein-
zelnen Services direkt schützen kann. So
muss sich dieser in einen J2EE-Container
einpluggen, damit er die Zugriffe auf die
einzelnenEJBs(EnterpriseJavaBeans)und
Webservices abfangen und überprüfen
kann.
Der Access Manager von Sun zum Bei-
spiel stellt Plugins für alle gängigen Web-
und Application-Server zur Verfügung.
Diese fangen den Request auf eine Res-
source (URL, EJB, WS usw.) ab und über-
prüfen,obderBenutzerbereitseinegültige
Sessionhat.Fallsnicht,werdendieCreden-
tials verlangt und an eine Instanz eines
zentralen Access Managers geschickt. Die-
ser wiederum überprüft, ob der User inner-
halb der Access Manager bereits eine gül-
tige Session hat und sendet gegebenenfalls
ein SAML-Token (Security Assertion Mar-
kup Language) an das Plugin zurück. An-
sonsten werden die Credentials überprüft.
Dabeikönnen,via«OutoftheBox»-Module
verschiedenste Agents, wie LDAP (Light-
weight Directory Access Protocol), Daten-
bank, Business Application, Certificates,
HTTP-Dienste, SAML-Provider eingebun-
den werden. Sind die Credentials in Ord-
nung, wird dem Plugin ein SAML-Token
zurückgeschickt und der Zugriff auf die
Ressource gewährt. Durch diesen Mecha-
nismusistautomatischeinWebSSO(Single
Sign-On) realisiert, denn die Session wird
auf dem zentralen Access Manager behal-
ten. Will sich der Benutzer nun in einer
alten Web-Applikation einloggen, die zum
Beispiel auf einem Apache-Server instal-
liert ist, so greift auch dort das Plugin und
sendetdenRequestandenAccessManager.
DieserkenntdieSessiondesBenutzersund
schickt direkt das SAML-Token an das Plu-
gin und der Benutzer ist authentifiziert.
Suns Access Manager unterstützt für das
Single Sign-On ebenso Cross Domain SSO
und Identity Federation. (Grafik 3)
Nachdem der Benutzer authentifiziert
ist, geht es darum auch die entsprechende
Autorisierung für die gewünschte Aktion
zu prüfen. Dazu werden Regeln definiert,
wer mit welcher Ressource was tun darf.
Diese Regeln werden Policies genannt. Sie
werden, entsprechend den Sicherheitsan-
forderungen, verschiedenen Ebenen zuge-
ordnet und können entweder binäre Ent-
scheidungen anhand von Rollen- oder
Gruppen-Zugehörigkeit oder auch Werte
von Attributen zurückgeben. Dem Access
Manager wird in der Konfiguration mitge-
teilt, wo sich das System befindet, in wel-
chem die Policies abgelegt sind.
Identity Management und SOA
WiebereitsEingangserwähnt,mussfüreine
sichere SOA nicht nur die Authentisierung,
sondern auch die Autorisierung zentral er-
folgen. Auch die Services und Composite
Applications brauchen einen sauberen und
durchgängigenSchutz.SoisteinklaresMa-
nagement der Benutzer und seiner Rechte
unabdingbar.
Gekaufte Lösungen wie SAP, Peoplesoft
oder Siebel, beinhalten meist bereits eine
eigene Benutzerverwaltung mit eigenen
Passwörtern. Möglicherweise besitzt man
aber auch noch alte Host-Anwendungen,
eine User-Verwaltung im Active Directory
für die Windows-Accounts oder einen zen-
tralen LDAP für Webanwendungen. In
Grossfirmen haben zudem die Benutzer oft
verschiedene User-Namen in diesen Syste-
men. Das bedeutet, dass die Passwörter
überall manuell gepflegt werden müssen.
Damit die Rechte auf die Services dele-
giert werden können und diese mit dem
Benutzer direkt auf die Backend-Systeme
gehen,istesunabdingbar,dassdieBenutzer
inallenSystemendengleichenBenutzerna-
men haben und deren Rechte entsprechend
synchronisiertwerden.Diesgeschiehtdurch
die Provisionierung von Benutzern und de-
ren Rechten. Moderne Identity-Manage-
ment-Systeme, wie beispielsweise der Sun
Identity Manager, übernehmen diese Auf-
gabe.DasProvisionierenundDeprovisionie-
ren der Daten in den Backend-Systemen
erfolgt ohne Installation von Agents.
MitCompositeApplicationsaufderBasis
von klar definierten SOA-Layern können
neue Business-Applikationen sehr schnell
realisiert werden. Dabei ist wichtig, dass
die Security in jedem Layer und jedem Ser-
vice berücksichtigt wird. Identity Manage-
ment ist hierfür eine unabdingbare Grund-
lage. ■
Grafik 2: Deployment-Architektur.
Service Oriented Architecture
WWW.COMPUTERWORLD.CH / 15. SEPTEMBER 2006 45