====== 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:
===== Adressen (Personen) =====
Eine Adresse ist entweder ein Mitarbeiter, ein Debitor, ein Kreditor, eine Organisationseinheit, oder eine einfache Adresse((Was ein ziemlich unglückliches Objektmodell ist. Im Grunde sollte eine Adresse wirklich nur eine Anschrift sein. Dann sollte es Debitore, Kreditore, Organisationseinheiten, Mitarbeiter und Personen geben. Eine Person kann nun eine Rolle innehaben, die es ihr erlaubt, einen Mitarbeiter darzustellen, einem Debitoren zugeordnet zu werden, einem Kreditor, usw. Aber einen Mitarbeiter als Kindklasse einer Adresse zu sehen, auf derselben Ebene wie ein Debitor, Kreditor und eine Organisationseinheit, vermischt so einiges auf einer völlig falschen Ebene.)). Abhängig des Adresstyps kann die Adresse weitere Rechte erhalten, z.B. als Mitarbeiter im Projekt:
===== Mitarbeiter =====
Der Adresstyp Mitarbeiter kann im Projekt diverse Rechte erhalten. Er kann Administrative Rechte erhalten((Verträge anlegen und definieren, Leistungen abrechnen, Zeitdatensätze genehmigen)), oder das Recht, eigene Zeitdatensätze zu erfassen((als Projektmitarbeiter)).
\\ \\ 
Zudem kann ein Mitarbeiter im Organisationsbaum Rollen erhalten, die ihm Organisatorische Rechte zusprechen.
==== Autorisierung ====
Es gibt somit 5 Rechtesysteme in PRO•M 1.0. Die allgemeinen Rechte über die Benutzerkonten, die Administrativen Projektrechte für die Autoren der Projekte, die Administrativen Projektrechte über die Projektrollen, die Genehmigungsrechte im Projekt über die Genehmigungsrolle und die organisatorischen Rechte über die Organisationsrolle.
==== Die Vermischung ====
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**//, // 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.
\\ \\ 
Wenn die Zuordnung vom Benutzerkonto zur Person in PRO•M 1.0 fix wäre, könnte man das anders sehen. In dem Fall könnte man es so deuten, dass ein Benutzerkonto eine Rolle hat, die es als Person darstellt. Über die Zuordnung wäre die Person eindeutig identifizierbar, und wenn ein Benutzerkonto authentifiziert ist, wäre das gleich zu setzen mit der Authentifizierung der Person.
\\ \\ 
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.