Differences

This shows you the differences between two versions of the page.

--- concepts:identityandaccesscontrol:authentication [2013/01/02 16:33]
rtavassoli
+++ concepts:identityandaccesscontrol:authentication [2013/06/26 16:33] (current)
rtavassoli [Authentifizierung]
@@ Line 1: / Line 1: @@
 ====== Authentifizierung ======
 Das ist gar kein so leichtes Thema. Wenn wir uns P.A.C.((Vorgänger von PRO•M)), bzw. PRO•M 1.0 angucken, dann wird einiges vermischt, ohne es explizit zu machen, was dort vermischt wird.
+===== Key Koncepts =====
+siehe [[http://msdn.microsoft.com/en-us/library/z164t8hs.aspx]]
 ===== Benutzerkonten =====
 Es gibt das Benutzerkonto. Ein Konto wird einer Rechtegruppe zugeordnet, über die das Konto bestimme Zugriffsrechte erhält. Zudem kann das Konto einer Adresse((Mitarbeiter, Debitor, Kreditor, Organisationseinheit)) zugeordnet werden:
@@ Line 14: / Line 16: @@
 Daraus geht hervor, dass mal das Benutzerkonto autorisiert wird, mal der Mitarbeiter((entweder in der Rolle als Projektmitarbeiter oder als Orgazugehöriger)). Wo liegt das Problem, was wird vermischt? Das Benutzerkonto und die Adresse werden vermischt.
 \\ \\
-Bei der Anmeldung wird das Benutzerkonto über den Loginnamen und das Kennwort authentifiziert. Nicht aber die Adresse, bzw. der Mitarbeiter. Es wird angenommen, dass das Benutzerkonto ein Mitarbeiter //ist//, was aber nicht dem Objektmodell((eigentlich Datenmodell, da hier nichts Objektorientiert ist)) entspricht. Das Benutzerkonto //ist// keine Person((Adresse)), es //ist// auch keiner Person zugeordnet, sondern es //hat das Recht eine Person zu **impersonieren**//.
+Bei der Anmeldung wird das Benutzerkonto über den Loginnamen und das Kennwort authentifiziert. Nicht aber die Adresse, bzw. der Mitarbeiter. Es wird angenommen, dass das Benutzerkonto ein Mitarbeiter //ist//, was aber nicht dem Objektmodell((eigentlich Datenmodell, da hier nichts Objektorientiert ist)) entspricht. Das Benutzerkonto //ist// keine Person((Adresse)), es //ist// auch keiner Person zugeordnet, sondern es //hat das Recht eine Person zu **impersonieren**//, // im Auftrag der Person zu handeln//.
 \\ \\
 Dieses Recht wird dem Benutzerkonto nicht explizit gegeben, sonder implizit über die Zuordnung. Bei der Anmeldung wird das Benutzerkonto authentifiziert, nicht aber die Person. Die Person wird niemals authentifiziert. Dem Benutzerkonto wird aber an diversen Stellen erlaubt, im Namen der Person zu handeln! Im Grunde wird dem Benutzerkonto somit ein //Impersonationsrecht// für eine bestimmte Person gegeben.
@@ Line 21: / Line 23: @@
 \\ \\
 Da man die zugeordnete Person aber verändern kann, muss man es so sehen, dass lediglich das Benutzerkonto identifiziert wurde. Bei allen weiteren Aktionen die Person betreffend muss die Person in der Aktion identifiziert werden, und die Aktion des Benutzerkontos die Person betreffend muss autorisiert werden - in anderen Worten, es muss geprüft werden, ob das Benutzerkonto die Person impersonieren darf.
+==== Die Lösung ====
+Es gibt nicht //die Lösung//. Im Grunde gibt es 2 Ressourcen, das Benutzerkonto und den Mitarbeiter, und beide Ressourcen habe bestimmte Rechte. Mal wird eine Aktion im Kontext eines Benutzerkontos durchgeführt, mal im Kontext eines Mitarbeiters. Die unterschiedlichen Autorisationsstellen benötigen für die Autorisierung mal das Benutzerkonto, mal den Mitarbeiter, d.h. es werden tatsächlich unterschiedliche Rechteobjekte((Benutzerkonto, Mitarbeiter)) autorisiert, nur dass in PRO•M implizit definiert wird, dass ein Benutzerkonto einen Mitarbeiter impersonieren darf.
+=== Impersonierung explizit machen ===
+Man müsste am Modell nichts ändern. Authentifiziert wird weiterhin nur das Benutzerkonto. Nach der Anmeldung wird zudem((wie auch jetzt)) abgefragt, wen das Benutzerkonto impersonieren darf. Wenn dann z.B. //eigene// Zeitdatensätze erfasst werden, schickt das Front-End die ID des Mitarbeiters mit, für den die Zeitdatensätze gelten. Die Autorisierungsstelle für Zeitdaten benötigt den Mitarbeiter als Ressource, d.h. sie muss prüfen, ob die authentifizierte Ressource((in diesem Fall der Mitarbeiter)), die den Befehl sendet, dem Mitarbeiter entspricht, für den der Zeitdatensatz gilt. Die authentifizierte Ressource ist aber ein Benutzerkonto, und kein Mitarbeiter. Daher müsste erst geprüft werden, ob das Benutzerkonto den Mitarbeiter impersonieren kann((es wird implizit davon ausgegangen, dass das Konto auch den Mitarbeiter impersonieren möchte, für den der Zeitdatensatz gilt, und nicht für einen anderen)). Danach kann die Aktion für den Mitarbeiter autorisiert werden.
+\\ \\
+Zusammengefasst((Zurzeit gibt es eine Autorisierungsstelle für Aktionen im Kontext des Benutzerkontos und im Kontext des Mitarbeiters. Das ist ein //big ball of mud//, und es ist //schöner// das in mehrere Kontexte aufzuteilen, daher diese komplexe Analyse)):
+  * Ein Zeitdatensatz für einen Mitarbeiter darf nur von dem Mitarbeiter selbst erfasst werden,
+  * Authentifiziert ist ein Benutzerkonto,
+  * Die Mitarbeiterauthentifizierungsstelle prüft nun, ob das Benutzerkonto den Mitarbeiter impersonieren darf((Hier werden die 2 getrennten Kontexte wieder zusammengeführt, d.h. es muss eine Schnittstelle geben, die diese Impersonation vom Benutzerkonto-Kontext zum Mitarbeiterkontext herstellt)),
+  * Die Aktion wird dann für den Mitarbeiter autorisiert
+=== Mehrfachauthentifizierung ===
+Für manche Rechteprüfungen muss //ich// wissen, welches Benutzerkonto Urheber der Aktion ist, für andere muss ich wissen, welcher Mitarbeiter Urheber der Aktion ist. Es gibt sogar Fälle, in denen eine Aktion von beiden Autorisierungsstellen geprüft wird. Ein Benutzerkonto kann z.B. allgemeine Rechte haben((z.B. //darf Alles genehmigen//)), ein Mitarbeiter Projektspezifische. Die Autorisierung der Aktion wird in diesem Fall verkettet. Dafür muss es zwei authentifizierte Ressourcen geben.
+\\ \\
+Die Applikation meldet sich hierfür zunächst mit dem Benutzerkonto an. Dann wird das Benutzerkonto dazu verwendet, dass sie sich mit dem Mitarbeiter anmeldet. Dafür gibt es eine eigene Mitarbeiter-Authentifizierungsstelle, die einfach die authentifizierten Daten eines Benutzerkontos verwendet, um den Mitarbeiter zu authentifizieren.
+\\ \\
+Die zweite Authentifizierungsstelle muss somit der ersten vertrauen. Über ein einfaches Mapping((wie z.B. zurzeit, eine einfache Referenz vom Benutzerkonto zum Mitarbeiter)) kann definiert werden, welcher Mitarbeiter mit welchem Benutzerkonto authentifiziert werden kann.
+=== Benutzerkonto und Person zusammenführen ===
+Das scheint am sinnvollsten. Die Diskussion der ersten beiden Möglichkeiten hat gezeigt, dass die aktuelle Trennung recht künstlich ist.

tawiki

User Tools

Site Tools

Differences

Page Tools