concepts:identityandaccesscontrol:authorization
Differences
This shows you the differences between two versions of the page.
|
concepts:identityandaccesscontrol:authorization [2013/02/14 16:21] rtavassoli created |
concepts:identityandaccesscontrol:authorization [2014/01/19 17:54] (current) rtavassoli [Das Modell ist das Problem] |
||
|---|---|---|---|
| Line 3: | Line 3: | ||
| \\ \\ | \\ \\ | ||
| 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. | 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 ===== | ===== Fälle in denen das Read Model versagt ===== | ||
| Angenommen es gibt folgende Befehle | Angenommen es gibt folgende Befehle | ||
| Line 23: | Line 25: | ||
| \\ \\ | \\ \\ | ||
| 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. | 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. | Es gibt somit keine Königslösung. Wie in so vielen Fällen hängt die Lösung davon ab, was gefordert ist. | ||
concepts/identityandaccesscontrol/authorization.1360855309.txt.gz · Last modified: 2013/02/14 16:21 by rtavassoli
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 3.0 Unported
