Das Identitätsmanagement Dilemma

Was ist Identitätsmanagement und warum ist es so wichtig?

Seit ich mit der Java Entwicklung angefangen habe, war ich immer der Meinung, der schwierigste Teil der Softwareentwicklung wäre die technische Umsetzung im Code selber. Das Bauen eines GUI’s, das Implementieren eines Webservices, das Einbauen von Logik im Backend etc.

Mit der Zeit merkte ich aber, dass dies nicht der grosse Brocken war, der den Aufwand schluckte. Ein weiterer grosser Brocken waren die Diskussionen mit den Stakeholdern zu ihren Anforderungen. Aber das ist nicht der Teil, auf den ich hier eingehen will. In diesem Beitrag spreche ich vom Aufbauen einer Architektur, von technischen Diskussionen mit Architekten und der Konzeption von etwas Neuem.

Damit ich einen konkreten Fall haben, den man anschauen kann, nehme ich an, dass die Migros eine „Superidee“ hat: Wegen Kosteneinsparungen hat die Migros keine Lust mehr, die Superpunkte ihrer Kunden selber zu speichern, und will einen Kanal zu Coop aufbauen, um die Verwaltung der Superpunkte an Coop abzugeben.

Die Vorstellung von Migros ist folgende: Der Kunde loggt sich in das Migros Portal ein und klickt auf einen Knopf „Ja, ich möchte von jetzt an meine Superpunkte von Coop verwaltet haben“ und ZACK meldet Migros den Kunden bei Coop an und übergibt die ausstehenden Superpunkte.

Und wo ist jetzt das Identitätsmanagement?

Identitätsmanagement befasst sich in der Welt der Datenverarbeitung mit der Verwaltung von Benutzerdaten, die einzelnen Personen zugeordnet sind. In diesem Beispiel haben wir gleich zwei Entitäten, welche Benutzer verwalten: Migros und Coop.

Die Synchronisation dieser zwei Systeme birgt jetzt aus architektonischer Sicht einige Herausforderungen:

– Technisch: Wie kommunizieren die zwei Firmen miteinander?
– Aus Datensicht: Beide Firmen benutzen andere Datentabellen / ID’s für ihre Kunden
– Rechtlich: Darf Migros Daten seiner Kunden aus rechtlicher Sicht überhaupt an Coop weiterreichen?
– Und ganz wichtig: Wie finden Migros und Coop heraus, dass sie vom gleichen Kunden sprechen?

Problem: Wie einigt man sich auf denselben Kunden?

Wir haben zum Beispiel den Kunden King Kong. Er ist Kunde bei Migros sowie auch bei Coop. King meldet sich nun beim Migrosportal an, klickt auf den Coop-Knopf und Migros übermittelt seine Daten an Coop. Coop nimmt die Daten und sucht den richtigen King Kong in seiner Datenbank.

Hier gibt es potentiell etliche Fehlervarianten, die passieren können:

– King Kong ist vor einem Jahr gezügelt, hat den Umzug aber nur Coop gemeldet -> Kunde matcht nicht
– King Kong hat bei der Eingabe seiner Adresse bei Coop einen Tippfehler gemacht -> Kunde matcht nicht
– Coop findet gleich drei King Kong’s, die alle ähnliche Daten gespeichert haben, welcher ist der richtige?
etc.

Natürlich kann man viele Attribute des Kunden nehmen, um diese in der Datenbank zu finden. Und die Wahrscheinlichkeit, dass es mehrere King Kong’s mit Geburtsdatum 02.02.1984 gibt, ist wohl gering. Doch Benutzerdaten sind jeweils nur so gut, wie sie gepflegt werden (das erinnnert mich daran, dass ich meinen Blumen wieder mal Wasser geben sollte).

Wie löst man dieses Dilemma?

Aus sicherheitstechnischer Sicht kann man diese Herausforderung lösen, indem man den Kunden sich selbst bei Coop authentifizieren lässt. Wie wir im Artikel Was ist 2-Faktor Authentifizierung? gesehen haben, ist ein Benutzername und ein Passwort dazu da, einen Kunden zu authentifizieren. Wenn der Kunde sich also bei Migros oder bei Coop anmeldet, dann können die Firmen sicher sein, dass es sich um den gleichen Kunden handelt.

Da es sich hier aber nicht um einen einfachen Login handelt, sondern quasi um einen doppelten Login (einmal bei Migros und einmal bei Coop) könnte man folgendermassen vorgehen:

1. Der Kunde loggt sich beim Migros Portal (mit seinem Migros Login) ein
2. Der Kunde drückt den Knopf „Ja, ich möchte von jetzt an meine Superpunkte von Coop verwaltet haben“
3. Das Migros Portal öffnet ein Popup, in dem es die Portalseite von Coop öffnet, und zeigt den Login
4. Der Kunde loggt sich beim Coop Portal ein (mit seinem Coop Login)
5. Da der Kunde sich selber authentifiziert hat, weiss Coop, dass es sich um den Kunden King Kong handelt.
6. Migros und Coop müssen nun noch ihre jeweiligen ID’s des Kunden austauschen und speichern.
7. Migros kann von nun an alle anlaufenden Superpunkte an den Kunden bei Coop schicken

Das ist jetzt nur mal die architektonische Idee. Für technische Details werde ich einen weiteren Blogeintrag schreiben.

Wie Sie sicherlich festellen können, ist die Umsetzung eines solchen Projektes durchaus aufwändig. Am Ende läuft es vielleicht auf einen Webservice hin, mit dem Migros an Coop melden kann „Kunde King Kong hat im Dezember 500 Superpunkte bekommen“ – Bis dieser Prozess aber läuft, sind viele Meetings und Workshops abzuhalten, Designs zu erstellen und Securityentscheidungen zu treffen.

Werbeanzeigen

Wie starre Prozesse eine Firma in die Knie zwingen können

Wir hatten also dieses neue Projekt, welches hunderttausende von Dateien verarbeiten musste. Das Problem war, dass wir nicht sicher sein konnten, wie schnell die Performance im laufenden Betrieb schlussendlich sein würde. Und in den Testumgebungen hatten wir nicht genügend Testdaten, um die Auslastung im Produktionsumfeld auch nur annähernd zu erreichen.

Das war damals eine Java Spring JMS Webapplikation. Wie es zu deren Natur gehört, hatten wir eine Konfigurationsdatei, in der wir etliche Parameter (Anzahl Threads etc.) einstellen konnten.

Nun waren wir aber alles andere als „Agile“ aufgestellt. Wir hatten jeweils nur wenige Releases pro Jahr. Natürlich gab es einen Prozess für ausserordentliche Lieferungen: Wenn es irgendwo brannte, musste man schnell reagieren und eventuelle Bugs beseitigen. Diese Prozesse gingen aber relativ lange und brauchten immer eine Unmenge von administrativem Aufwand. Und wenn man etwas liefern/beheben wollte, war das meistens ein recht negatives Erlebis. Man musste sich quasi das Recht erkämpfen, doch bitte die Software korrigieren zu können, damit der Kunde die Applikation funktionsgerecht verwenden konnte.

Verstehen Sie mich nicht falsch. Natürlich muss man mit allen Mitteln (Unittests, automatisierten Integrationstests etc.) verhindern, dass eine solche Situation entsteht. Doch eine solche Abneigung gegenüber Veränderung empfand ich als sehr lästig. Und heutige Informatiksysteme sind so gross, komplex und unüberschaubar geworden und miteinander verwoben, dass es durchaus Folgereaktionen geben kann, die man so nicht erwartet hätte. Nur schon die Vorstellung, man könnte alle Folgereaktionen und Abhängigkeiten einer Einlieferung wissen, ist absurd.

Wir wollten also Fehler beheben. Wir wollten auch eine möglichst gute Performance hinkriegen. Doch in der Realität haben wir die Parameter der Konfigurationsdatei initial bestimmt, so gut wir diese verstanden haben, und nachfolgend nur noch einmal angepasst. Wenn man jedesmal einen Marathon laufen muss, um einen Wert in einer Datei zu ändern, lässt man es irgendwann sein und hofft, dass doch alles noch gut kommt.

Ich hätte mir gewünscht, dass wir die Parameter öfters hätten ändern können – Und zwar in kleinen Schritten, um zu verstehen, welche Parameter wirklich etwas an der Performance verändern und das System beschleunigen oder verlangsamen. Aber was wir uns auch überlegten, jeder Schritt endete in einem administrativen Prozess, bei denen wir höchstens zwischen „mühsam“ und „einigermassen erträglich“ haben wählen können.

Wenn ich dann höre, dass in „fully agile Projekten“ eine unkomplizierte Anpassung der Produktion jeden Tag möglich ist, werde ich schon ein wenig neidisch. Ob es in der Realität in agilen Projekten wirklich so unkompliziert vonstatten geht?