Identity As A Service

SOA-Modell jetzt auch mit Identitätsmanagement

02.03.2007 | Autor / Redakteur: Martin Kuppinger und Tim Cole / Peter Schmitz

Modulare Software-Entwicklung und enge Prozessintegration gelten als Garanten für den Erfolg im Markt für Identity & Access Management. Speziell bei SOA klaffen Wunsch und Wirklichkeit aber weit auseinander. Es gilt daher schon früh die richtigen Voraussetzungen für solche Anwendungen zu schaffen um dann die Früchte der Modularisierung ernten zu können, meinen Martin Kuppinger und Tim Cole.

Alle reden von SOA (Service Oriented Architecture) – inzwischen auch die Hersteller Lösungen für das Identity & Access Management (IAM). Die Idee ist in der Tat reizvoll: Statt das Rad jedes Mal neu zu erfinden können Entwickler einfach in die Grabbelkiste bereits vorhandener Software-Module klauben und sich das Passende – etwa für die Passworteingabe, für digitale Zertifikate oder auch anspruchsvolle Lösungen im, Bereich der Biometrie – oder für die neue Anwendung herausklauben. Das Ergebnis: Die Entwicklungszyklen können deutlich verkürzt werden, die IT kann deshalb schneller und besser auf die sich verändernden Bedürfnisse des Business reagieren und kommt dabei auch noch mit schmäleren Budgets aus.

Leider klaffen Wunsch und Wirklichkeit bei SOA weiter auseinander als sonst wo in der Unternehmens-IT. Das liegt zu einen an dem Begriff selbst, der verwirrend ist und viele falsche Erwartungen weckt. In Wahrheit geht es weder um Architekturen noch um Service, wie Prof. Gunter Dueck, Chief Technologist von IBM Deutschland, kürzlich auf einem Symposium in München treffend feststellte, sondern um die Integration von Geschäftsprozessen und unterstützender IT-Infrastruktur in Form von sicheren, standardisierten Komponenten. Dueck schlug vor, statt SOA künftig von BOA zu reden, nämlich „Business Oriented Architecture“. Was im deutschen noch den zusätzlichen Vorteil der Ähnlichkeit mit einem Ausdruck zustimmenden Erstaunens („Boa, eh!) mit sich bringt.

Nun ist der Ansatz von SOA ja nun nicht wirklich neu. Auf unterschiedlichen Ebenen hatten CORBA (Common Object Request Broker Architecture) oder das IBM „San Francisco“-Projekt von Anfang an vergleichbare Ziel im Auge. SOAs rücken aber an zunehmend in den Mittelpunkt, weil insbesondere mit Web Services die Integration von Diensten innerhalb und außerhalb des Unternehmens viel einfacher und schneller möglich wird. Web Services sind eine plattformunabhängige Lösung, die relativ einfach nutzbar ist – vor allem, weil immer einfachere Web Service-Schnittstellen in Anwendungen und Plattformen wie dem Microsoft .NET Framework implementiert werden.

Durch die Integration solcher Dienste über das Web, oder aber auch innerhalb eines Unternehmensnetzwerks, lassen sich insbesondere Geschäftsprozesse einfacher umsetzen, weil die innerhalb eines Geschäftsprozesses erforderlichen Schritte als Dienste abstrahiert werden können. Die Anwendung verbindet dann „nur“ die Dienste in der erforderlichen Reihenfolge.

Gerade hier spielt Identity Management als Basistechnologie eine immer wichtigere Rolle, denn wer sichere Geschäftsprozesse oder andere SOA-basierende Anwendungen realisieren möchte, muss sicher sein, dass nur diejenigen solche Dienste in Anspruch nehmen, die dafür die richtige Berechtigung besitzen. Es geht also darum, auch im SOA-Zeitalter Identitäten über die verschiedenen genutzten Dienste hinweg zu beherrschen.

Nehmen wir beispielsweise den JSR (Java Specification Request) 208, der sich mit der Java Business Integration (JBI), einem wichtigen Element für die Umsetzung von SOAs im Java-Umfeld, beschäftigt. Auffällig ist, das das Thema Sicherheit hier praktisch keine Rolle spielt. Das ist leider bei neuen Standards häufig der Fall, weil die Entwickler etwas ganz anderes im Kopf hatten, als sie sich an die Arbeit machten. Dinge wie Sicherheit und Identity Management werden dann nachträglich mehr oder weniger elegant angeflanscht. Mit dem Ergebnis, dass solche Systeme häufig nach Jahren noch an Sicherheitslücken und versteckten Hintertüren für Hacker leiden.

Auch bei der Entwicklung von Web Services hat man sich erst viel später Gedanken darüber gemacht, wie diese nun denn auch sicher und verlässlich gemacht werden können. Gerade bei SOAs können so erhebliche Fehlinvestitionen entstehen in Anwendungen, die unter dem Aspekt der Sicherheit nicht verwaltbar sind.

Die Sicherheit ist aber nur eine von vielen Fallstricken, in die unbedarfte Entwickler im SOA-Umfeld tappen können. Viel gravierender sind die Herausforderungen an die Definition solcher Dienste, da sie oft Kernbereiche des Unternehmens und damit das Business selbst tangieren. Aus Unternehmenssicht heißt das, dass die Entwickler versuchen müssen, spezifische Funktionen auf einer höheren, generischen Ebene zu beschreiben, damit sie auch für zukünftige Anforderungen nutzbar sind und nicht zum „one off“ degenerieren – was ja dem Geist – und dem Charme – von SOA komplett widerspräche.

Systemmanagement und Identity Management

Bei SOAs liegt der Fokus der Anwendungsentwicklung darin, der Funktion zum Prozess zu verlagern. Das bedeutet aber auch, dass die Infrastruktur Anforderungen unterstützen muss, die zwangsläufig verteilt sind. Bis heute ist der Bereich der Anwendungsinfrastruktur relativ gut gelöst, wo Application Server und Frameworks eine breite Unterstützung für den Aufbau SOA-basierender Anwendungen bieten.

Anders sieht es beim Systemmanagement aus. Dort gilt der Fokus auch heute noch überwiegend dem Status einzelner Server. Das reicht für verteilte Prozesse aber nicht mehr aus, weil man sich dort die Frage stellen muss, ob der gesamte Prozess „gesund“ ist. Das ist vor allem bei Prozessen, die auch Dienste außerhalb des Unternehmens nutzen und die vielleicht zukünftig einmal in der Lage sein werden, dynamisch zwischen Dienstanbietern zu wechseln, eine erhebliche Herausforderung. Hier sind die Anbieter aus dem Bereich des ESM (Enterprise Systems Management) emsig dabei, Lösungen zu schaffen.

Bleibt also noch die Sicherheit, und hier insbesondere das Thema Identity Management. Ein sicherer Geschäftsprozess sollte dem Konzept der End-to-End-Security folgen. In einer SOA-Umgebung lautet beispielsweise die Forderung: Jeder Benutzer soll sich nur einmal gegenüber dem Prozess authentifizieren müssen und kann dann mit dieser Identität über den gesamten Prozess hinweg arbeiten. End-to-End-Security bedeutet auch, dass alle Zugriffe auf Dienste im Kontext dieser Identität erfolgen.

Die Realität sieht aber anders aus. Der Zugriff auf einen Dienst erfolgt häufig im Kontext eines administrativen Accounts. Die Anwendung steuert dagegen im Code, welche Informationen der aktuelle Benutzer sehen darf. Solche „fest verdrahtete“ Sicherheit ist ein Problem, weil sie später nicht mehr nachvollziehbar (Stichwort: Compliance!) und nur unter hohem Aufwand änderbar ist.

Nun darf die Forderung aber auch nicht lauten: Alle Dienste müssen alle potenziellen Benutzer kennen. In der Praxis bieten Rollenkonzepte einen einfachen Weg, Benutzer zusammenzufassen und zu abstrahieren. Der Zugriff auf Dienste erfolgt dann über das Rollemanagement und nicht das individuelle Benutzerkonto.

Dafür ist aber eine Infrastruktur erforderlich, die die rollenbasierte Zuordnung von Benutzern übernimmt und die in der Lage ist, Rollen oder Gruppen (je nach Dienst) zu verwalten. Identitäten müssen ebenfalls verwaltet und Informationen über Identitäten flexibel zwischen der SOA-basierenden Anwendung und den Diensten ausgetauscht werden können.

Ohne eine solche Identity Management-Infrastruktur sind keine sicheren, wartbaren und revisionsfähigen Geschäftsprozesse möglich.

Zwar lässt sich Sicherheit durchaus vorgaukeln, etwa indem man sie eben wie beschrieben codiert. Die Nachvollziehbarkeit darüber, wer was darf, fehlt in diesem Fall aber. Wenn man die wachsenden Anforderungen der Innenrevision und der Wirtschaftsprüfer bedenkt, ist das nicht mehr tolerierbar. Anders ausgedrückt: Wer SOAs einführt, ohne vorher an das Identity Management zu denken, entwickelt komplett an den eigentlichen Anforderungen des Business vorbei.

Welches Identity Management für SOA?

Wie lassen sich die Herausforderung Identity Management im Kontext von SOAs lösen? Es gibt inzwischen ein erfreulich breites Spektrum an Ansätzen. Keiner davon ist für alle Anforderungen gleichermaßen gut geeignet. Für das Unternehmen geht es also um die richtige Auswahl von Produkten und gegebenenfalls auch die richtige Kombination verschiedener Verfahren.

Identity Federation ist natürlich die nahe liegende Lösung für Identity Management im Kontext von SOAs. Diese sollen ja in der Lage sein, flexibel austauschbare Dienste zu nutzen. Diese zwangsläufig lose Kopplung charakterisiert auch die Identity Federation mit ihren Standards für den Austausch von Identitätsinformationen zwischen verschiedenen Systemen. Innerhalb eines Geschäftsprozesses kann eine vertraute Stelle für die Authentifizierung definiert werden. Diese stellt Identitätsinformationen wie beispielsweise Rollenzuordnungen für die Dienste im Prozess bereit, die diesen Informationen vertrauen. Das Modell des „circle of trust“, das eine Grundlage von modernem Identity Federation bildet, zwingt sich hier geradezu auf.

Federation ist für Anwendungen, die auch auf externe Dienste zugreifen müssen, ohnehin die denkbar beste Lösung. Innerhalb von Unternehmen sind aber auch andere Vorgehensweisen denkbar. Am anderen Ende der Skala stehen Verzeichnisdienste, die von allen Diensten genutzt werden. Das Konzept solcher zentralen Verzeichnisdienste ist allerdings heutzutage bei Entwicklern und Administratoren nicht mehr besonders beliebt, weil sie dazu neigen, zu komplex zu werden, wenn viele Anwendungen und Dienste ihre spezifischen Informationen darin speichern sollen. Für einen Teil der Dienste können solche Lösungen aber durchaus sinnvoll sein, vor allem wenn neben einem zentralen Verzeichnisdienst mit eigenen Anwendungsverzeichnissen gearbeitet wird, die von diesen Diensten mitgenutzt werden. Diese lassen sich wiederum über Meta Directory-Dienste koppeln.

Ein anderer Weg zu Identity als Service führt über das so genannte Provisioning, bei dem es um die Prozesse geht, die nötig sind, um einen Anwender eines IT-Systems mit den grundsätzlichen Voraussetzungen für seine Tätigkeit auszustatten. Im Rahmen der automatisierten Benutzerverwaltung werden in einem definierten Prozess Änderungen in verschiedene Systeme geschrieben. Provisioning ist deshalb so reizvoll, weil es nicht so komplex ist wie ein Meta Directory und trotzdem in der Lage, gleichzeitig Änderungen an vielen Stellen in nachvollziehbarer Weise umzusetzen.

Identity Management als Service

Identity Management im Zusammenhang mit Anwendungsarchitekturen lassen sich durchaus auch als ein Satz von Diensten verstehen, die sich sehr gut für die Modularisierung innerhalb eines SOA eignen. Identity Management ist jedoch kein Selbstzweck, sondern verspricht konkreten Nutzen. Dabei stehen solche nicht-technischen Vorteile wie Compliance, schnellere und leichtere Administration sowie Anwendungssicherheit im Vordergrund. „Identity as a service“ wird unserer Meinung nach mittelfristig zu einer sichtbaren Veränderung der Schnittstellen führen, aber auch dazu, dass IT-Abteilungen den Nutzen von Identity Management sehr viel besser gegenüber dem Business-Management werden darstellen können. Es liegt in der Natur eines Dienstes, dass sich sein Vorteil unmittelbar ergibt, während er bei einer Technologie in der Regel abstrakt beleibt und auf Umwegen argumentiert werden muss.

Klar ist aber in jedem Fall, dass Identity Management die Voraussetzung ist für sichere SOA-Anwendungen. So setzt Identity Federation beispielsweise einen Identity Provider voraus, dem alle vertrauen können. Ohne eine integrierte und vertrauenswürdige Identität ist so etwas schlichtweg nicht möglich. Wer heute noch mit einem „Identitätschaos“ aus vielen nicht integrierten Verzeichnisdiensten und redundanten Informationen arbeitet, kann sich jeden Gedanken an moderne Federation-Lösungen im Grunde sparen. Investitionen in das Identity Management rechnen sich folgerichtig alleine schon deshalb, weil damit die Voraussetzungen für flexible, effiziente und sichere Geschäftsprozesse überhaupt erst geschaffen werden.

Kommentare werden geladen....

Kommentar zu diesem Artikel

Der Kommentar wird durch einen Redakteur geprüft und in Kürze freigeschaltet.

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Kontaktieren Sie uns über: support.vogel.de/ (ID: 2002914 / Mobile- und Web-Apps)