IAM & SOA – Zwangsheirat oder Liebeshochzeit
Themen wie Business Agility und Flexibilisierung der Geschäftsprozesse gewinnen für Unternehmen schon seit Längerem immer mehr an Bedeutung. Nur wer selbst flexibel und agil genug ist, kann sich den Herausforderungen des Marktes stellen. Heutzutage funktioniert das Business mehr denn je nach dem Motto „Wer zuerst kommt, mahlt zuerst„.
Funktionieren kann dies nur mit einer hochintegrierten IT. Sie muss der geforderten Flexibilität gewachsen sein.Die aktuelle Situation ist leider eine andere: „Schon wieder ein neues Tool für Deine Abteilung? Wer soll das administrieren? Ich kann nichts versprechen, aber in vier oder fünf Wochen kümmere ich mich mal darum.“
Das Management und die Abteilungsleiter des Unternehmens geben sich nicht mehr mit solchen Aussagen seitens der IT zufrieden. Sie können es sich einfach nicht mehr leisten zu warten, bis die IT mal wieder Zeit für fachliche Problemstellungen findet. Demgegenüber steht die IT, die fast schon panisch reagiert, wenn neue Tools eingesetzt werden sollen. Tools, die fachliche Problemstellungen adressieren, sind meist als so genannte Insellösung konzipiert. Die Folgen davon sind jedem IT Mitarbeiter wohl bekannt: Insellösungen sind schlecht bis gar nicht in die Umgebung zu integrieren – manuelle Administration ist die Konsequenz.
SOA lindert Kopfschmerzen
Gerade, das häufig mitgelieferte Benutzermanagement bereitet der IT Kopfschmerzen, weil es sich wie eine Blackbox verhält. IAM Systeme versprechen hier Abhilfe, weil sie die Administration von Benutzerkonten vereinheitlichen. Dazu müssen sich die Systeme in eine heterogene IT-Umgebung integrieren lassen. Die Hersteller von solchen IAM-Systenen versuchen diese Integration zu erreichen, indem sie ihren Produkten eine Vielzahl von Schnittstellen spendieren. Das ist allerdings nur die halbe Miete. Vielmehr muss sich die Organisation der IT der geforderten Flexibilität stellen. Dies geht nur mit grundlegenden Konzepten. SOA ist ein Ansatz, weil einzelne SOA-Dienste für konkrete fachliche Aufgaben zuständig sind. Jedem ist bekannt, dass Serviceorientierte Anwendungen prädestiniert sind, Geschäftsprozesse von Seiten der IT zu unterstützten.
Gerade zur Identifikation von Services ist eine Prozessanalyse, die nur in Zusammenarbeit mit den Fachanwendungen erfolgen kann, unbedingt erforderlich. Allerdings setzten gut implementierte und sichere Geschäftsprozesse einen Identitätsnachweis voraus. Das übergeordnete Thema lautet hier Compliance. Für Serviceorientierte Architekturen bedeutet dies, dass einzelne Dienste nicht anonym – das heißt von jedem beliebigen Client – genutzt werden dürfen, sondern eine Autorisierung vor der eigentlichen Nutzung erfolgen muss. Damit die Flexibilität aufrecht erhalten werden kann, ist es von entscheidender Bedeutung, dass die Authentifikation und Autorisierung von Nutzern auf Service-Ebene erfolgt, nicht auf Client Ebene. Es wird deutlich, dass eine Serviceorientierte Architektur nicht ohne ein integriertes Benutzermanagement funktionieren kann. Gerade bei einer Vielzahl von Services spielt das Identity Management eine große Rolle. Die Themen, die hier adressiert werden müssen, sind Provisioning und Federation. Insofern handelt es sich hier einerseits um eine Zwangsheirat, weil SOA ohne IAM nicht funktionieren kann, und um eine Liebeshochzeit, weil sich IAM perfekt in ein SOA-Umfeld integrieren lässt.
Die Verteilung der Zuständigkeiten scheint mir echt noch eine Herausforderung zu sein. Zentral scheint mir einerseits die Aussage von Matthias Neher zu sein, dass die Authentifikation und Autorisierung von Nutzern auf Service-Ebene erfolgt, nicht auf Client Ebene. Damit ist geklärt, wer dafür sorge zu tragen hat. Noch nicht wer den Service erbringt. Ein zentrales IAM System kann und sollte sicherlich die Athentifizierungs-Services erbringen. Dies ist sicher darstellbar, da die zu erbringenden Services in diesem Kontext relativ klar eingrenzbar sind. Komplexer wird die Geschichte schon bei der Autorisierung, wenn diese neben Rollen auch noch Zustände der selbst verwalteten Daten (z.B. Kontosaldo, Limite, Verfügungen) berücksichtigen muss (siehe Anmerkung von Konrad Krafft). Um nun dem Anspruch der Flexibilisierung (s.o.) gerecht zu werden, sollte man ja unbedingt vermeiden Entscheidungen über fachliche Sachverhalte in ein IAM-System zu verlagern. Andererseits sollte nicht jede Businesskomponente ihre eigene ACCES-Verwaltung aufsetzen. Ein Königsweg könnte sein: das IAM-System als Lager für Rechte aller Art zu verwenden und die fachliche Autorisierungs-Entscheidung in den Business-Komponenten zu platzieren, die dazu auf die selbst verwalteten Daten und die IAM-Services zugreifen.
Man muss jeodch bei den vorhandenen Sicherheitslösungen unterscheiden, welchen den Schutz von Services auf Funktionsebene (einfacher Fall) und welche den Schutz auf Datenebene (komplizierter Fall) zu Verfügung stellen.
Andere Sicherheitsssysteme haben diesen Aspekt auch schon außer Acht gelassen (siehe Java(JAAS) oder CORBA(CORBA Security Service)).
Ein Schutz auf Datenebene bedeutet eine völlig andere Konzeption der Services, die an die SOA angebunden werden sollen. Die Services sollen einen zentralen IAM-Services nutzen, über den zentral alle Identitäten und deren Berechtigungen verwaltet werden können. Über diesen zentralen IAM-Service können die übrigen Services alle Daten filtern, sodass immer nur die Daten herausgegeben werden, auf die das fragende Subjekt berechtigt ist.
Hierfür existieren allerdings keine standardisierten Schnittstellen in bekannten IAM-Systemen, die für die jeweils fachlichen Services Möglichkeiten bieten, bestimmte Rollen oder Rechte zu publizieren.
SOA impliziert aus dem Architekturansatz heraus und weniger von der per Definition her die angesprochenen Sicherheitsaspekte.
Z.B. ist bei IBM Websphere der Aufbau von serviceorientierte Umgebungen (SOA) auf einer breiten Sicherheitsbasis möglich. Außerdem lassen sich Appliances mit der Sicherheitsmanagement-Software von Tivoli verbinden. Beide Instrumente sollen helfen, eine SOA-Infrastruktur aufzubauen, die sich nicht in den zahlreichen Complianceforderungen verheddern.
Sehr guter Artikel!
Mir fehlt jedoch noch die Problemstellung der Autorisierung auf Datenebene. Services stellen häufig nicht nur Funktionen, sondern auch Daten zur Verfügung, die je nach Berechtigung gefiltert werden müssen.
Gerade in einer IT-Landschaft, die sich mühsam das Vertrauen der Fachabteilung verdienen muss, ist es notwendig, dass die gewählte Infrastruktur, die Daten schützt, die ihr von den Fachabteilungen anvertraut werden.
Genau hier kann ein IAM System, das als Service in einer SOA konzipiert ist, als Grundpfeiler für die Sicherheit dienen.