Das ist gar kein so leichtes Thema. Wenn wir uns P.A.C.¹⁾, bzw. PRO•M 1.0 angucken, dann wird einiges vermischt, ohne es explizit zu machen, was dort vermischt wird.

siehe http://msdn.microsoft.com/en-us/library/z164t8hs.aspx

Es gibt das Benutzerkonto. Ein Konto wird einer Rechtegruppe zugeordnet, über die das Konto bestimme Zugriffsrechte erhält. Zudem kann das Konto einer Adresse²⁾ zugeordnet werden:

Eine Adresse ist entweder ein Mitarbeiter, ein Debitor, ein Kreditor, eine Organisationseinheit, oder eine einfache Adresse³⁾. Abhängig des Adresstyps kann die Adresse weitere Rechte erhalten, z.B. als Mitarbeiter im Projekt:

Der Adresstyp Mitarbeiter kann im Projekt diverse Rechte erhalten. Er kann Administrative Rechte erhalten⁴⁾, oder das Recht, eigene Zeitdatensätze zu erfassen⁵⁾.

Zudem kann ein Mitarbeiter im Organisationsbaum Rollen erhalten, die ihm Organisatorische Rechte zusprechen.

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.

Daraus geht hervor, dass mal das Benutzerkonto autorisiert wird, mal der Mitarbeiter⁶⁾. 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⁷⁾ entspricht. Das Benutzerkonto ist keine Person⁸⁾, 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.

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⁹⁾ autorisiert, nur dass in PRO•M implizit definiert wird, dass ein Benutzerkonto einen Mitarbeiter impersonieren darf.

Man müsste am Modell nichts ändern. Authentifiziert wird weiterhin nur das Benutzerkonto. Nach der Anmeldung wird zudem¹⁰⁾ 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¹¹⁾, 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¹²⁾. Danach kann die Aktion für den Mitarbeiter autorisiert werden.

Zusammengefasst¹³⁾:

• 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¹⁴⁾,
• Die Aktion wird dann für den Mitarbeiter autorisiert

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¹⁵⁾, 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¹⁶⁾ kann definiert werden, welcher Mitarbeiter mit welchem Benutzerkonto authentifiziert werden kann.

Das scheint am sinnvollsten. Die Diskussion der ersten beiden Möglichkeiten hat gezeigt, dass die aktuelle Trennung recht künstlich ist.