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.

Noch mehr Software Architektur Prinzipien


Gemäss IEEE ist Architektur

Die organisierte Struktur eines Systems oder einer Komponente.

Um diesen Systemen Herr zu werden, müssen bestimmte Punkte von einem Architekten beachtet werden. Die folgende Liste soll eine Ahnung davon geben, was bei einem System alles beachtet werden muss:

1. Modularität
Eine Architektur setzt sich aus Modulen zusammen. Ein Modul soll dabei möglichst in sich geschlossen sein. So ist es möglich, diese Module bei Bedarf auszutauschen (Siehe auch das Thema der Microservices).

2. Portabilität
Portabilität bei einer Software bedeutet, dass die Applikation oder Teile davon so gebaut worden sind, dass sie auch in anderen Umgebungen lauffähig sind .

3. Formbarkeit
Ein System soll möglichst formbar sein, um flexibler auf Anforderungen reagieren zu können. Dies kann etwas erreicht werden, in dem man allgemeine Systemfunktionen von fachspezifischen Funktionen trennt.

4. Konzeptuelle Integrität
Teile eines Systems, welche ähnliche Funktionen haben, sollten auch ähnlich gebaut werden. Es soll sich dabei an Standards und Referenzarchitekturen einer Firma gehalten werden.

5. Intellektuelle Kontrolle
Ein System- und Softwaredesign soll von den dafür Verantwortlichen in vollem Masse hinsichtlich Inhalt und Komplexität verstanden werden.

6. Machbarkeit
Ein umzusetzendes System- oder Softwaredesign soll so spezifiziert werden, dass es von einem gegebenen Team in einer gegebenen Zeit umgesetzt werden kann. Das Team muss über das entsprechende Knowhow verfügen und das Zielsystem muss in die momentane Architektur eingepflegt werden können.

Das Decorator Pattern ist wirklich praktisch!

Mit dem Decorator Entwurfsmuster kann man auf einfache Art eine bestehende Klasse um eine Funktionalität erweitern, ohne diese Klasse verändern zu müssen. Und was ganz cool ist: Man kann auch Decorators von Decorators von Decorators machen, um beliebig viele Zusatzfunktionen ineinander zu verschachteln. Decorateception! (Ob das dann noch übersichtlich ist, ist eine Frage für einen weiteren Blogeintrag).

Das Decorator Pattern zeigte mir auch wieder einmal die Flexibilität, die hinter Interfaces steckt.

Das Grossbuchstaben-Problem

Ich habe eine Applikation, die von einer Klasse Mitarbeiter den Namen holt. Das Doofe ist jetzt aber, dass der erste Buchstabe immer klein geschrieben ist, ich benötige ihn aber gross geschrieben. Und was noch doofer ist: Es ist mir technisch unmöglich, diese Klasse nachträglich zu ändern.

Was kann ich also machen?

decoratorpatterngliffy-problem

Klick mich für das Bild in gross

Die Lösung visualisiert

Die Lösung ist einfach: Ich packe eine neue Klasse MitarbeiterDecorator um die Klasse Mitarbeiter. Und was beinhaltet diese Klasse? Sie implementiert dasselbe Interface Person wie Mitarbeiter. Konkret bedeutet dies, dass die Decoratorklasse diesselben Methoden wie Mitarbeiter implementieren muss. Der Clou dabei ist nun, dass ich im Decorator einen Mitarbeiter erstelle, und in jeder Methode vom Decorator jeweils die gleiche Methode von Mitarbeiter aufrufe.

getName() vom MitarbeiterDecorator ruft also getName() vom Mitarbeiter auf.

Und nun kann ich entweder vor oder nach diesem Methodenaufruf beliebige Funktionen einfügen, um den Namen zu verändern. In diesem Fall füge ich nach dem Holen vom Namen im MitarbeiterDecorator noch eine Logik ein, die sicherstellt, dass der erste Buchstabe gross geschrieben ist.

decoratorpatterngliffy-loesung

Klick mich für das Bild in gross

Lösung in einem Codebeispiel

Die wichtigen Codestücke für dieses Beispiel sind folgende:

1. Der aufrufenden Applikation gebe ich statt einem Mitarbeiter einen MitarbeiterDecorator zurück – in den ich den Mitarbeiter gleich reinsetze, um dessen Methoden aufrufen zu können.

Aus

return mitarbeiter;

wird

return new MitarbeiterDecorator(mitarbeiter);

Die neue Klasse MitarbeiterDecorator sieht dann folgendermassen aus:

public class MitarbeiterDecorator implements Person {

private Mitarbeiter mitarbeiter;

public MitarbeiterDecorator(Mitarbeiter mitarbeiter){
    this.mitarbeiter = mitarbeiter;
}

public String getName(){

    // rufe die Methode der Mitarbeiterklasse auf
    String name = mitarbeiter.getName();

    // Stelle hier sicher, dass der erste Buchstabe gross ist
    name = Character.toUpperCase(name.charAt(0)) 
    + name.substring(1, name.length());

    return name;
}
}

Warum sind hier Interfaces so cool?

Im Codebeispiel sieht man, warum hier Interfaces eine geniale Erfindung sind: Die Aufruferapplikation programmiert (gemäss genereller programmierempfehlungen) gegen das Interface Person. Ich kann nun einfach statt des Mitarbeiters den MitarbeiterDecorator zurückgeben – Da beide Klassen „Personen“ sind, stört das die Aufruferapplikation nicht.

Fazit

Ich hoffe, das Beispiel hat die Genialität des Decorator Pattern darlegen können. Ich möchte hier noch ergänzend sagen, dass man das Pattern auch mit einer abstrakten Klasse statt einem Interface machen kann.