tawiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Autorisation ======
//"Authorization is orthogonal to the domain"//. In anderen Worten ist die Autorisation in den meisten Domänen((mit Ausnahme der Autorisations-Domäne)) nicht expliziter Bestandteil der Domäne, und sollte so gebaut werden, dass sie so wenig intrusiv ist wie möglich.
\\ \\
In den meisten Fällen kann einfach der Befehl genommen werden, zusammen mit dem authentifizieren Anwender, und es wird geprüft, ob der Anwender das Recht hat, den Befehl auszuführen. Ein Problem besteht, wenn der Befehl nicht alle notwendigen Informationen beinhalten, um ihn autorisieren zu können. Der Prozess der Autorisierung kann in dem Fall das //read model// bemühen, um die notwendigen Informationen zu ermitteln.
===== Key Koncepts =====
siehe [[http://msdn.microsoft.com/en-us/library/z164t8hs.aspx]]
===== Fälle in denen das Read Model versagt =====
Angenommen es gibt folgende Befehle
  * Lege Termin für Mitarbeiter in Projekt an
  * Ändere Termin auf einen anderen Mitarbeiter
  * Ändere Termin auf ein anderes Projekt
  * Ändere die Termin Details
Angenommen es gibt folgende Rechte
  * Mitarbeiter dürfen eigene Termine anlegen und beliebig ändern
  * Projektleiter dürfen Termine in ihren Projekten für alle Mitarbeiter anlegen und beliebig ändern
Jetzt passiert folgendes
  - Mitarbeiter ABC legt einen Termin in Projekt P1 für sich selbst an
  - Mitarbeiter XYZ, Projektleiter im Projekt P1, bucht den Termin auf Mitarbeiter DEF um, und ändert dabei einige Details des Termins
  - Mitarbeiter ABC ändert die Details des Termins
Schritt 3 sollte nicht mehr möglich sein wenn Mitarbeiter ABC nicht Projektleiter im Projekt P1 ist. Wenn die Autorisierung aber lediglich das //read model// verwendet, und die Umbuchung des Termins auf Mitarbeiter DEF im //read model// noch nicht sichtbar ist, wenn der dritte Befehl abgeschickt wird, würde der dritte Befehl autorisiert werden, weil der Absender und Termininhaber((im Lesemodell, nicht in der Domäne!)) beide Mitarbeiter ABC sind. Mitarbeiter ABC würde somit fälschlicherweise einen Termin für Mitarbeiter XYZ ändern.
===== Das Modell ist das Problem =====
Der Workflow von oben zeigt, dass das Modell problematisch ist. Wenn ich Termindetails ändern möchte, schicke ich zwar meine Logindaten mit, damit der Service weiß, dass ich, Mitarbeiter ABC, die Änderungen abschicke. Aber weder in den Logindaten, noch im Befehl, steht drin, wem der Termin gehört. Der Befehl lautet z.B. "Ändere die Terminlaufzeit auf 08:00-12:00 für den Termin mit der ID 355DD55321EE".
\\ \\
Im Grunde müsste ich den Befehl darüber autorisieren, indem ich mir die Entität(en), für die der Befehl gilt, hole, sie analysiere, und dann prüfe, ob der Befehlsgeber die nötigen Rechte für die gewünschten Änderungen hat. Ich würde mir also den Termin mit der Nummer 355DD55321EE holen, gucken für wen er ist, und dann prüfen, ob der Aufrufer das Recht für die gewünschte Änderung hat.
\\ \\
Das Modell ist also nur problematisch, wenn ich mit einer Kopie des Termins arbeite((aus dem read model)), und den Befehl genehmige, ohne zu wissen, ob die Kopie überhaupt noch aktuell ist. In manchen Fällen mag das in Ordnung sein, z.B. wenn die relevanten Daten unveränderlich sind. In anderen Fällen kann es problematisch sein. In diesen Fällen müsste man sich die Entitäten direkt über Repositories geben lassen, in dem Wissen, dass der Befehl dann auch auf genau diese Entität angewendet wird((Geladene Entitäten im Aufruf müssen also gecached werden können)). Zudem **müssen die relevanten Eigenschaften des Befehls abfragbar sein**. CQS sollte immer zur Anwendung kommen, CQRS nur bedingt.
\\ \\
Zusammenfassend braucht der Autorisierer ein konsistentes Lesemodell um konsistent autorisieren zu können. Dafür wird die Domäne((die Aggregates)) am einfachsten unter Einhaltung von CQS Eigenschaften veröffentlichen. Wenn weitere Eigenschaften für einen neuen Autorisierer benötigt werden, muss die Domäne halt erweitert werden. Zudem muss der Autorisierer sich daran halten, nur die __Q__uery Methoden der Aggregates zu verwenden, und keine __C__ommand Methoden.
\\ \\
Wüsste man im Vorfeld immer, welche Daten zum Autorisieren benötigt würden, würde der Autorisierer feste Methoden in der Domäne aufrufen, z.B. Aggregate.AuthorizeSetStatusWith(StatusId, this). Das Aggregate würde in der Methode im Autorisierer wiederum dieselbe Methode aufrufen((this wäre in diesem Fall IAuthorizeSetStatus)), dabei((konsistent)) alle weiteren Eigenschaften übergeben.
\\ \\
Da das Autorisieren aber flexibel eingehängt werden können soll, und mal vom Mitarbeiter des Zeitdatensatzes abhängen kann, mal vom Projektvorgang, mal vom Kunden, usw.....
\\ \\
Ahhhhhh!!! Der Kunde kann ja niemals konsistent geprüft werden. Angenommen, ich darf einen Datensatz des Kunden ABC genehmigen, den von XYZ nicht - das darf niemand. Wenn ich nun einen Datensatz von Kunden ABC genehmige, und gleichzeitig der Kunde des Zeitdatensatzes auf XYZ geändert wird, das Lesemodell((der Kunde ist nicht Teil des Zeitdatensatzes und muss über das Lesemodell ermittelt werden)) aber noch ABC hat, würde die Änderung genehmigt werden - und es gibt eine Zustand "Zeitdatensatz für Kunden XYZ ist genehmigt", den es gar nicht geben dürfte.
\\ \\
Das muss somit noch anders gelöst werden. Veröffentlichen von Eigenschaften aus dem Aggregate heraus ist nur eine Teillösung, die das eigentliche Problem überhaupt nicht angeht!!!
\\ \\
Es gibt somit keine Königslösung. Wie in so vielen Fällen hängt die Lösung davon ab, was gefordert ist.
tawiki

User Tools

Site Tools

Page Tools
