Die fictive ACME AG ("A Company Manufacturing Everything") verwendet zur Arbeitszeiterfassung ein etabliertes ERP-System mit Web-Oberfläche und eigener Benutzerverwaltung. Im Zuge steigender Anforderungen an die Sicherheit wird die Passwort-Policy für das System verschärft mit dem Effekt, dass die Helpdesk-Kosten aufgrund vergessener Passwörter sprunghaft steigen. Das ist einerseits ein Problem, andererseits aber der Grundstein für ein erfolgreiches IdM-Projekt ein Business Case. Eine Single-Sign-on-Lösung (SSO) mit Password-Self-Services würde die Helpdesk-Kosten wieder reduzieren und zudem Benutzerkomfort und Sicherheit erhöhen.

Erster Schritt: Business Case

Ein klar definierter und nachvollziehbarer Business Case ist deshalb entscheidend, weil die Bereitschaft, Geld für neue Infrastrukturprojekte wie IdM aufzuwenden, typischerweise gering ist. Die Skepsis rührt zum einen daher, dass mit einem IdM-Vorhaben oft Eingriffe in organisatorische Strukturen und die IT-Administration verbunden sind. Dabei werden etablierte Prozesse und Verantwortungsbereiche angetastet. Zum anderen ist IdM ein relativ neues und abteilungsübergreifendes Thema. Daher sind oft nicht einmal die organisatorische Zuständigkeit und die Finanzierungsmodelle für IdM in einem Unternehmen geklärt.

Der Business Case ist die Rechtfertigung und der Treiber für das Vorhaben. Er kann strategisch oder finanziell motiviert sein. Neben dem klassischen RoI wird inzwischen auch der "Return on Security Investment", kurz: ROSI, betrachtet.

Um das Interesse von Entscheidungsträgern und Budgetverantwortlichen zu wecken, gilt es, mit dem Business Case im Unternehmen hausieren zu gehen, das Vorhaben zu vermarkten und einen Sponsor dafür zu finden. Ein fester Rückhalt durch das Management ist eine Grundvoraussetzung für ein erfolgreiches IdM-Projekt. Der Einführung von IdM muss eine strategische Entscheidung zugrunde liegen, andernfalls ist ein Scheitern programmiert.

Auch IT braucht Strategie

Letzten Endes ist IT immer Mittel zum Zweck. Selbst wenn sie noch so gut ist, kommt ihr meist nur eine unterstützende Rolle zu. Aber auch in der IT müssen Unternehmen eine langfristige Strategie verfolgen, die an den Geschäftszielen ausgerichtet ist. Die IT-Strategie beantwortet Fragen, die auch für das IdM-Programm relevant sind. Inwieweit ist die Abhängigkeit von einem einzelnen Hersteller zu akzeptieren? Welche Risiken sind akzeptabel, um Wettbewerbsvorteile zu erzielen und die eigene Marktposition zu verbessern? Verfolgt das Unternehmen eine eher konservative IT-Strategie und hat es sich darauf festgelegt, nur ausgereifte und am Markt etablierte Produkte und Technologien einzusetzen, wird es Probleme bereiten, ein brandneues Virtual-Directory-Produkt einzusetzen - mag es auch noch so viel versprechende Merkmale bieten.

Die IdM-Strategie muss sich an der übergeordneten IT-Strategie ausrichten. Aber da, wo Letztere Freiheiten lässt, sollte die IdM-Strategie klar Stellung beziehen, um Wildwuchs in der IdM-Landschaft der Organisation zu vermeiden.

IdM: In kleinen Schritten zum Erfolg

Aus den fachlichen Business Cases werden technische Use Cases abgeleitet, die wiederum in die Anforderungsanalyse eingehen. Der Nutzen, den ein solcher Anwendungsfall bringt, lässt sich in sechs Kategorien bewerten, die den allgemein genannten geschäftlichen Treibern für IdM entsprechen. Diese Kategorien wirken sich auf verschiedene Parteien aus: Die Einführung von SSO wird den Anwender unmittelbar erfreuen, Compliance-Maßnahmen sind gesetzlich erforderlich, während sich die Notwendigkeit von Security-Maßnahmen oft erst dann zeigt, wenn etwas schiefgegangen ist.

Die Kriterien sollten nach den eigenen Zielen gewichtet werden. Dann gilt es, die Use Cases nach den Kriterien zu bewerten und mit den Maßnahmen zu beginnen, die unmittelbaren Nutzen für den Business Case bringen. Dabei muss nicht im ersten Projekt gleich die letzte angestaubte Host-Anwendung in das Provisioning-System eingebunden werden. Die Projekte sollten mit Meilensteinen definiert und IdM als fortlaufendes Programm betrachtet werden.

Ziele müssen im Rahmen bleiben

IdM ist ein Thema mit großer Tragweite. Daher findet sich bei vielen Firmen in der IdM-Landschaft weites Brachland also jede Menge Felder, die es zu beackern gilt. Daher sollte man das eigene Terrain genau abstecken. Beim Aufbau eines Zuliefererportals können nicht im gleichen Zug alle Probleme aus dem Mitarbeiterumfeld gelöst werden.

Der Kontext des jeweiligen Projekts wird neben den Use Cases durch die nichtfunktionalen Anforderungen und die IT-Governance, sprich: die Ausrichtung der IT an den Geschäftszielen, bestimmt. Dies gilt es im Auge zu behalten. Der "Scope Creep", die schleichende Ausweitung des Projektkontextes ohne Kontrolle der Veränderungen, ist eines der größten Risiken von IdM-Projekten.

IdM: Alle Betroffenen früh einbeziehen

Zu einer Anwendung bei einem Partnerunternehmen soll ein SSO über Federation-Technik etabliert werden. Der Business Case steht, das Budget ist bewilligt, die Produktentscheidung wird getroffen und eine Testumgebung mit einem Test-Directory sowie einem J2EE-basierenden Federation-Server aufgesetzt, der als Identity Provider für das Unternehmen agiert. Alles läuft perfekt und ist bereit für die Live-Schaltung mit Anbindung an das unternehmensweite Active-Directory als verlässliche Quelle für die Authentisierung. Alles? Wenn da nicht der Verantwortliche für das Active Directory mit dem Argument käme, dass kein Benutzer sein Windows-Passwort in dieses System eingeben dürfe, weil es dort kompromittiert werden könnte. In diesem Fall spielt es keine Rolle, ob das Argument technisch tragfähig ist - der Systemverantwortliche sitzt am längeren Hebel und kann so seine politischen Interessen durchsetzen.

IdM-Programme haben demnach auch eine politische Komponente. Was technisch machbar ist, lässt sich im Unternehmen noch lange nicht durchsetzen. Deshalb ist es unumgänglich, bereits in einer frühen Phase des Projekts alle beteiligten Parteien einzubeziehen, ihre Interessen zu verstehen und zu einem Konsens zu gelangen. Auch nichtfunktionale Randbedingungen wie Sicherheitsrichtlinien müssen beachtet werden. Einverständniserklärungen und Genehmigungen sollten unbedingt schriftlich dokumentiert werden.

Wichtig ist es, zu kommunizieren und sich auf ein gemeinsames Vokabular zu einigen, um nicht aneinander vorbeizureden. Auch gilt es, die technischen Alternativen eines Produkts zu erläutern und die Vor- und Nachteile aufzuzeigen, um von Seiten der Fachabteilung eine Entscheidung herbeizuführen. Auch Letztere sollte dokumentiert werden.

Das zahlt sich aus, wenn etwa fünf Web-Anwendungen, die in drei Browser-Fenstern laufen, erfolgreich in einen SSO-Verbund integriert wurden und dann plötzlich die Diskussion etwa um die Auswirkungen vom Klick auf einen Logout-Button beginnt: "Warum kann ich in Anwendung A nicht weiterarbeiten, ich habe mich doch nur in Anwendung B abgemeldet?"

Für Datenqualität sorgen

Ein unternehmensweites Metadirectory oder Provisioning System erhebt den Anspruch, die zentrale Drehscheibe und definitive Quelle für Identity-Daten zu sein. Um diesem Anspruch gerecht zu werden, ist es maßgeblich, auch die Qualität der Daten zu sichern. Wenn das System 500 "Test User" aus "Entenhausen" liefert, gerät man in Erklärungsnot, egal in welchem der angeschlossenen Quellsysteme der Datenmüll seinen Ursprung hat. Dies trägt nicht zur Akzeptanz des Systems bei.

Um eine hohe Datenqualität zu sicherzustellen, sind ein hohes Maß an Kommunikation mit den Verantwortlichen der Quellsysteme und geregelte Prozesse erforderlich. So sollte bereits bei der Erfassung von Identity-Daten in den HR-Systemen auf Vollständigkeit, Namenskonventionen und einheitliche Schreibweisen geachtet werden. Idealerweise werden solche Prüfungen in das User-Interface integriert, um Fehler schon bei der Eingabe zu vermeiden. Auch das Etablieren einer unternehmensweit eindeutigen User-ID ist eine enorme Erleichterung bei der Konsolidierung von Datensätzen. Dem IdM-System bleiben lediglich Plausibilitätsprüfungen und die Bereinigung von Dubletten. Dies ist allerdings ungleich komplexer und aufwändiger.

IdM-Produktkauf: Die Qual der Wahl

Die Anforderungsanalyse kann Kriterien liefern, durch die bestimmte Produkte von vornherein auszuschließen sind. Der IdM-Markt wird jedoch inzwischen durch Hersteller von kompletten Suiten, Spezialisten und Open-Source-Projekte so weit abgedeckt, dass sich eine definitive Entscheidung für ein Produkt allein anhand der Anforderungsanalyse kaum treffen lässt. Vielmehr müssen die Situation im Unternehmen und dessen strategische Grundsätze einbezogen werden. Gibt es bereits Beziehungen zu einem Hersteller? Entstehen Synergien durch Supportverträge oder Unternehmenslizenzen? Ist ein Hersteller als strategischer Partner gesetzt? Ist Know-how zu ähnlichen Produkten vorhanden? Gibt es Einschränkungen durch die Betriebssystem-Plattform?

Vorteilhaft ist in der Regel, auf offene Standards und Schnittstellen zu achten, um das Produkt durch eine Serviceschicht zu kapseln und gegebenenfalls später austauschen zu können. Diese Vorgehensweise vermeidet allzu verpflichtende Entscheidungen und entspricht dem Trend weg von einer produktzentrischen Sicht hin zur Service-orientierten Infrastruktur.

Mit dem Begriff "IT-Security" assoziiert der Privatanwender sofort das Thema "Online-Banking". Doch nicht nur im Bankenumfeld spielt das Thema Sicherheit eine Rolle. Jedes Unternehmen, dessen Wertschöpfungskette vorwiegend auf Informationsverarbeitung beruht, sollte ein angemessenes Sicherheits- und Risiko-Management betreiben.

Das mag zwar bei einem "Car-Konfigurator" im Internet weniger relevant sein. Kein Automobilhersteller aber möchte die CAD-Daten seines neuesten Prototypen aus einer Filesharing-Börse herunterladen können ganz zu schweigen von dem schwer zu messenden Schaden durch Image-Verlust, der mit solchen Vorfällen einhergeht. Insofern unterscheiden sich die Branchen in den Anforderungen an eine IdM-Lösung wenig. Das kann sich allerdings durch das an Bedeutung gewinnende Thema Compliance ändern, da auch branchenspezifische gesetzliche Regulierungen zu erwarten sind.

Deutlicher fallen die Unterschiede in Bezug auf die Firmengröße aus. Während in großen Konzernen generische Frameworks im Mittelpunkt stehen, zielt der Mittelstand eher auf kurzfristigen Nutzen durch direkte Integration seiner Systeme ab. Aufgabe des IdM ist es aber auch, geeignete Schnittstellen für die Zusammenarbeit dieser Parteien im B-to-B-Umfeld zu liefern.

IdM: Abschied vom Directory-zentrischen Weltbild

Insbesondere in der Automobilindustrie wird die Zusammenarbeit mit Partnern und Zulieferern stark intensiviert. Das wirkt sich auch auf die IT aus und erfordert eine Öffnung zu externen Märkten und IT-Systemen. Aber auch in anderen Branchen besteht der Bedarf, Applikationen von externen Service-Providern nahtlos zu integrieren. Daher ist ein klarer Trend zu Identity-Federation, dem domänen- und organisationsübergreifenden Austausch von Identity-Informationen, zu verzeichnen. Die zunehmende Interoperabilität der Standards und Produkte erleichtert die Entscheidung, in die Federation-Technik einzusteigen.

Allgemein steht Federation für den Austausch von Identity-Informationen im Internet. Aber im Firmennetz eines gewachsenen Konzerns herrschen mitunter ähnliche Strukturen, wenn die Tochterfirmen ihre eigenen Windows- und DNS-Domains haben. Daher können auch innerhalb eines Großunternehmens Federation-Ansätze zielführend sein, um die Interoperabilität zwischen Töchtern oder zum Outsourcing-Partner herzustellen.

Service-orientiert denken

Was in der Softwareentwicklung mit der objektorientierten Programmierung vor mehr als zehn Jahren Einzug gehalten hat, setzt sich nun auch im IdM durch: Information Hiding. Dabei gilt es, die Details der eigenen Datenhaltung zu verbergen und stattdessen Services und Schnittstellen offen zu legen. Niemand wird sich für die firmenspezifischen Verästelungen eines Directory-Baums interessieren und mit den technischen Details der LDAP-Programmierung (Lightweight Directory Access Protocol) herumschlagen wollen, um eine Business-Operation auszuführen wie: "Gib mir alle Rollen des Benutzers XY". Demnach gilt es, LDAP als Schnittstelle für den Directory-orientierten Zugriff bestehen zu lassen, aber prozessorientierte Operationen mit komplexerer Semantik in Form von Services anzubieten. Die Implementierung sollte in eine eigene Schicht, den "Identity Access Layer", gepackt werden. Ob hinter den Kulissen auf eine Datenbank oder auf ein Directory zugegriffen wird, ist für den Servicenutzer irrelevant. Dadurch lässt sich die enge Kopplung zwischen Anwendungen und Identitätsdaten auflösen, was mehr Flexibilität gewährt.

Für den Betrieb gewappnet sein

Auch wenn die Lasttests erfolgreich vorgenommen wurden, das System in die Produktion überführt und an den Betrieb übergeben worden ist, können noch Probleme auftauchen. Wenn sich aufgrund äußerer Bedingungen wie gesetzlicher Änderungen alle Benutzer an einem Stichtag in einer Portal-Anwendung anmelden wollen, kann die Zahl der Logins schnell alle Prognosen übertreffen. Das mag zunächst nach einem Fall für ITIL und Capacity-Management klingen. Kritisch ist allerdings, dass es sich bei IdM-Systemen um gemeinsam genutzte Infrastrukturen handelt. Eine Fehlfunktion in einer integrierten Anwendung kann die gesamte Infrastruktur beeinträchtigen und somit Nebenwirkungen auf alle anderen Systeme haben. Umfangreiche Last- und Integrationstests sind daher als Präventiv-Maßnahmen unumgänglich.

IdM als Corporate Lifestyle

Auch die kompletteste IdM-Lösung wird ein Schattendasein fristen, solange nicht im ganzen Unternehmen das Bewusstsein für die Nutzung der IdM-Dienste geschärft wird. Dazu müssen zunächst die organisatorischen Voraussetzungen und Finanzierungsmodelle geschaffen werden. Um die Nutzung der IdM-Services zu forcieren, sind Entscheidungen des Managements erforderlich. Idealerweise gibt es im Unternehmen bereits einen IT-Blueprint-Prozess, nach dem die IdM-Lösungen abgenommen und als strategischer Baustein vorgeschrieben werden.

IdM ist nicht als einmaliges, abgeschlossenes Projekt, sondern als fortlaufender Prozess zu betrachten. Es muss gelebt werden und sich in der IT-Strategie des Unternehmens verankern. Nur so ist die Nutzung der IdM-Services sicherzustellen und die Ausbreitung proprietärer Insellösungen zu unterbinden. Wer eine Corporate Identity hat, sollte am "Corporate Identity Management" nicht sparen. (kf)