Bin ich schon drin? Darf ich überhaupt rein? Gerade bei verteilten Systemen, Anwendungen und unterschiedlichen Verzeichnisstrukturen, die innerhalb einer SOA aus Dutzenden von Services gebaut werden, ist ein übergreifendes Management von Benutzern und ihren Rechten dringend angesagt. Konkret: Eine SOA kann ohne ein integriertes Benutzer- und Zugriffs (Access)-Management (Identity Access Management = IAM) nicht funktionieren. Die Themen, die IM adressiert, sind Provisioning und Federation. "Provisioning" steht für Beschaffung/Versorgung und bedeutet die Unterstützung für die notwendigen Schnittstellen. "Federation" steht für Vereinigung, also für das Vorhandensein notwendiger Standards.

SOA verfolgt die Idee, einmal getätigte Entwicklungen mehrfach zu nutzen (re-use). Ohne die Wiederverwendung blieben die eigentlichen SOA-Vorteile wie Flexibilität, Agilität und Kostenreduzierung aus. Es gilt jedoch, dass eine Applikation nicht automatisch Services für weitere Geschäftsprozesse bietet, nur weil diese mit J2EE oder .net realisiert wurde. Erst wenn die notwendigen Abstimmungen und Randbedingungen dieser weiteren Geschäftsprozesse in der Realisierung des Services mit eingebracht worden sind, handelt es sich um einen für weitere Geschäftsprozesse fähigen Service. Neben der rein theoretischen Kompatibilität der Services sollte man dabei Punkte wie Performance, Skalierung, Ausfallsicherheit und Netzwerkstruktur nicht vergessen. Nicht selten stellt sich nämlich heraus, dass Dienste auf Basis objektorientierter Technologien ein Performance-Limit haben, das sich nicht überschreiten lässt. Hier reicht es dann nicht einfach, die Hardware aufzumotzen, vielmehr ist es erforderlich, bestimmte Routinen zu optimieren.

Identity Management ist eine Art Instanz, die über den eigentlichen Anwendungssystemen stehen muss. Systeme richten sich dann im Laufe ihrer Lebenszeit an dieser Instanz aus. So werden alle Prozesse wie "Mitarbeiter neu", "Mitarbeiter wechselt Abteilung", "Mitarbeiterdaten ändern" oder "Mitarbeiter verlässt das Unternehmen" angepasst. Von daher ist klar, dass IM einen wesentlich längeren Lebenszyklus hat als Systeme und Prozesse, die sich daran ausrichten. Entscheidend ist nun dabei, dass IM nicht auf virtuelle Directories setzen. Vielmehr ist ein Unternehmen gut beraten, offene Standards wie LDAP strategisch festzulegen. Natürlich ist ein Aufwachen bei den meisten Unternehmen dahingehend notwendig, dass man übergreifende Strukturen schaffen muss, die in der Lage sind, langfristige Ziele wie IM und SOA zu realisieren. Die üblichen Strukturen, die für das Umsetzen von Projekten ausgelegt sind, sind für übergreifende Ziele wie SOA nicht geeignet. Hier bedarf es einer übergreifenden Kommunikation, Kompetenz, Verantwortung, Kontrolle, Fachwissens und des Segens der Geschäftsführung, da es durchaus länger dauern kann, bis sich solche Ansätze rechnen.

Flexibilität durch LDAP-Standard

Viele Anbieter legten Unternehmen nahe, als Alternative zu ihren heterogenen Systemstrukturen und Directory-Diensten einen zentralen Verzeichnisdienst zu schaffen. Das lässt sich jedoch angesichts der Vielfalt an gewachsenen Systemen überhaupt nicht umsetzen - zumindest nicht in größeren Unternehmen. Solche zentralen Strukturen werden zu komplex, um in der Praxis nutzbar zu sein. Selbst Microsoft hat sich mit der Ankündigung von "ADAM" als ergänzender Technologie für Anwendungsverzeichnisse von diesem Ansatz verabschiedet.

Um aber nun einen Wildwuchs zu verhindern, bei dem verschiedene Anwendungen unterschiedlichste Technologien nutzen, die später in der Administration und beim Sicherheits-Management nicht mehr beherrschbar sind, braucht man eine Strategie für Applikationsverzeichnisse. Konkret: Es muss ein einheitlicher Weg für den Zugriff definiert werden, wozu sich LDAP als bekanntester Mechanismus oder DSML als Web-Service- und XML-basierende Variante anbieten.

Wiederverwendbare Schnittstelle

Die Empfehlung der Fachleute lautet: offene Standards verwenden, besonders im Bereich Identity- und Access-Management. Als hilfreich hat sich dabei der Standard Lightweight Directory Access Protocol (LDAP) erwiesen. Durch ihn ist aus technischer Sicht bereits ein wesentlicher Teil des SOA-Ansatzes erfüllt, denn er garantiert das Schaffen von wiederverwendbaren Schnittstellen und damit die Erfüllung eines der wesentlichen Ziele von SOA.

Die organisatorische Sichtweise, Geschäftsprozesse in Services abzubilden, erfordert die genaue (firmenweite) Analyse und Ausarbeitung des zentralen Konzeptes.

Unternehmen sollten also ein führendes LDAP-System aufbauen und sich primär auf eine zentrale Verwaltung der Benutzerkonten auf Metaebene konzentrieren. Und das möglichst ohne virtuelle Directories (Meta Directories) sowie ohne die Einführung zusätzlicher Systeme und Datenbanken. Auf diese führende Metaebene sollten neue Anwendungen und Applikationen ausgerichtet werden. Access Management auf den Ressourcensystemen sollte so funktionieren, dass aufgrund von Metainformationen der Access Control Lists (ACLs) im LDAP Rollen und Freigaben vergeben werden. Das heißt, ein benutzerverwaltungsunabhängiges Ressourcen-Management bleibt auf jedem System bestehen. Das hat den Vorteil der Eigenständigkeit der Systeme - jedes System kann sein spezifisches Access Management bewerkstelligen.

Diese Vorgehensweise wird auch den bestehenden organisatorischen Gegebenheiten gerecht: So behält die SAP-Fachabteilung weiterhin die Kompetenzen, ihr System zu verwalten (die lassen sich nach unseren Erfahrungen die aufwendigen Rollenprofile ohnehin nicht wegnehmen). Die Mainframe-Abteilung sowie die PC-Netzwerkverwalter können weiterhin eigenständig ihre Systeme verwalten und erweitern, ohne aber parallel den Aufwand einer Benutzerverwaltung auf sich nehmen zu müssen. Zum Teil ist dieser Ansatz nur mit einem guten Konzept und den Standard-Bordmitteln der jeweiligen Systeme zu realisieren. Eine andere Möglichkeit bieten Integrationswerkzeuge, mit denen sich die restlichen Systeme und Anwendungen dem zentral verwalteten LDAP Directory unterordnen lassen.

Kompetenz klären

Lediglich das Access Management - der Zugriff auf Ressourcen - wird noch am jeweiligen System gemacht. Ansätze, Access-Management-Bereiche von den verschiedenen Anwendungen und Systemen auch an das zentrale LDAP zu verlagern, wird von vielen Unternehmen klar abgelehnt. Zu Recht, denn es würde technisch und auch organisatorisch eine unüberwindbare Hürde darstellen, die, wenn das Ganze zu schnell geht, auch Einschränkungen und Abhängigkeiten mit sich bringen kann. Würde man beispielsweise viele anwendungsspezifische Informationen in die Metaebene packen, wäre die Frage der Verwaltungskompetenz zu klären: Wer darf auf dieser Ebene operieren? Wildwuchs und Kompetenzgerangel würden entstehen.

Politische Hürden nehmen

Ganz wichtig ist, dass ganz besonders im Bereich IM die politische interne Komponente eine nicht zu vernachlässigbare Hürde darstellt, denn es geht um Kompetenzen, um Kommunikation, die oft nicht gewollt ist. Oft sind Firmenkonstellationen schwierig, und es ist eine klare Abgrenzung zwischen der Verwaltung von Berechtigungen und dem Zugriff auf Systeme nötig. Zu beachten ist, dass jeder weitere Service die Gesamtkomplexität des Systems erhöht und somit auch die Sicherheitsanforderungen steigen. Governance-Strukturen werden also immer wichtiger - Mechanismen, die dafür sorgen, dass Vorgaben auch eingehalten werden.

Um IM erfolgreich umzusetzen, gilt: Beachtung im Top-Management schaffen und Strukturen aufbauen, mit denen langfristig und projekt- und fachabteilungsübergreifende Ziele im Bereich IM und Security top-down realisierbar sind. Groß Denken ist dabei auf jeden Fall angebracht, also strategische Festlegung auf offene Standards im Bereich Identity Management wie LDAP und XML, an denen sich alle Entwicklungen nach und nach ausrichten.

Michael Wagner ist Geschäftsführer der Firma Comtarsia IT Services GmbH, Wien.