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.
Die zehn wichtigsten Projektschritte
Ziel der Lösung definieren;
Betroffene einbeziehen;
Ist-Situation analysieren;
Business Cases und Technical Use Cases definieren;
Anforderungen analysieren;
IdM-Strategie festlegen;
Proof of Concept;
Design der Lösung entwerfen (Migrationsstrategie, Risikoanalyse);
Implementierung, Test und Integration;
Migration, Betrieb, Support.
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?"