Vor dem Einsatz testen
Allerdings fiel das Web-GUI des Tivoli Identity Manager durch einige Schwachstellen auf: Administratoren haben zwar die Möglichkeit, Web-Seiten für Endanwender relativ einfach zu gestalten und zu modifizieren. Bestimmte Aktionen lassen sich jedoch nur ausführen, indem man Javascript-Code in Textfelder eingibt. Das erhöht die Komplexität der Lösung und ist nicht besonders elegant.
Dafür glänzt die Lösung mit einer Simulationsfunktion, die es dem Administrator erlaubt, Regeln auszuprobieren, bevor er sie "scharf" schaltet. Positiv hervorzuheben sind daneben die Workflow-Funktionen: Diese werden über ein Java-Applet grafisch dargestellt. Einzelne Arbeitsschritte lassen sich dabei einfach per Drag and Drop verschieben.
So wurde getestet
Die gesamte Teststruktur wurde auf einem "HP-Proliant-DL585"-Server mit vier "Opteron-252"-Prozessoren und 32 GB RAM aufgebaut. Als Betriebssystem kam Red Hats "Advanced Server 3" zum Einsatz, darauf installiert war "VMware GSX Server 3.1". Hierauf wurden fünf Windows Server 2003 konfiguriert sowie zwei "Fedora-Core-3"-Systeme. Für die Tests wurde eine Musterfirma vorgegeben, deren zentrale Organisationseinheit sich in Untergruppen wie Finanzbuchhaltung, Produktion und Versand gliederte. Insgesamt belief sich die Zahl der Angestellten auf 2270. Zu jedem User Object gehörte eine Reihe von Attributen wie Abteilungsnummer, Geburtsdatum und Adresse.
Zum Firmennetz zählten ein Exchange Server 2003, ein Windows-basierender File-Print-Server sowie ein IIS-Web-Server. Ein Apache-Web-Server lief auf einem der Fedora-Systeme, die HR-und ERP-Lösungen auf dem anderen. Um die Umgebung etwas abwechslungsreicher zu gestalten, kamen als zusätzliche Aufgabe noch ein z/OS-Emulator und ein Lotus-Notes-Server hinzu, die es einzubinden galt.
Die Hersteller erhielten die Grundinformationen über das Szenario einen Monat im Voraus. Im Labor mussten sie dann ihre Lösung implementieren und mit den restlichen Komponenten integrieren. Nach dieser Vorarbeit begannen die eigentlichen Herausforderungen: Ein neuer Angestellter (Harry) musste angelegt und mit den nötigen Rechten auf allen Systemen versehen werden. Dann wird Harry befördert, erhält also weitere Berechtigungen und wird Mitglied in einer speziellen Sicherheitsgruppe. Er lernt eine Angestellte (Sally) einer anderen Firma kennen. Noch vor der Hochzeit wird diese Firma von der ersten übernommen, weswegen zwei Active Directories zusammengeführt werden müssen. Außerdem muss das Provisioning von Anwendern von einem System in das andere bewerkstelligt werden, so dass sie über Domain-Grenzen hinweg auf Anwendungen und Dateien zugreifen können.
Nach dem Abschluss des Firmenkaufs heiraten Harry und Sally: Sie übernimmt seinen Namen, weshalb das System in der Lage sein muss, ihre Kennungen entsprechend zu ändern, ohne dass ihre Berechtigungen verloren gehen.
Harry leistet sich aber kurz darauf einen Fehltritt, indem er sich unberechtigt Zugang zum System verschafft. Er loggt sich mit der Kennung eines Administrators ein, erzeugt einen fiktiven User Account und stattet diesen mit den nötigen Privilegien aus, damit er die Abrechnungen und Gehaltslisten einsehen kann. Die Systeme sollten im Test diese Aktion erkennen und Gegenmaßnahmen einleiten.
Daraufhin wird Harry gefeuert, weswegen sämtliche Zugriffsrechte gelöscht und seine Konten aufgelöst werden müssen. Sally ist natürlich frustriert und reicht die Scheidung ein. Also muss die IDM-Lösung eine weitere Änderung über alle beteiligten Systeme hin vornehmen.
Gesamteindruck: Alles in allem ist Tivoli Identity Manager eine umfassende Lösung zu einem akzeptablen Preis, die ein solides Backend und großartige Integrations-Tools bietet. Allerdings dürfte es ohne externe Hilfe nicht ganz einfach sein, die Lösung in einem produktiven Netzwerk zu implementieren.