Die Aufteilung in Lese- und Schreibrechte ist nicht zwingend korrekt. Ein Recht ¹⁾ kann auch als Lese- und Schreibrecht verwendet werden. Es ist aber übersichtlicher, wenn man die Rechte entsprechend aufteilt. Rechte, die eine doppelte Rolle spielen, werden entsprechend zugeordnet, bzw. gekennzeichnet.

Es ist auch wichtig zwischen Rechten und der Autorisierung der Rechte zu differenzieren. Die Anwendung definiert die Rechte indem man für die Anwendung sinnvollerweise bestimmt, welche Rechte für welche Lese- und Schreib-Aktionen notwendig sind. Der Autorisierer bestimmt, wie diese Rechte genehmigt werden.

Teamrollen eines Mitarbeiters lesen zu dürfen hängt dabei z.B. sinnvollerweise vom Mitarbeiter ab, nicht von der Rolle. Wenn ich mir dann die Mitarbeiter zu einer Rolle angucken möchte, sehe ich auch nur die Mitarbeiter, für die ich das Recht habe, die Teamrollen zu sehen.

Eine Teamrolle für einen Mitarbeiter anlegen ²⁾ zu können hängt aber vom Mitarbeiter und der Rolle ab. Ein Betreuer soll keinen Einrichtungsleiter anlegen dürfen. Anders herum aber doch. Es könnte auch nur von der Rolle abhängen, und nicht vom Mitarbeiter, also komplett umgekehrt als bei den Leserechten.

Die Rechte zu bestimmen ist also eher eine Kunst als ein rein logischer, bzw. technischer Vorgang.

Zu unterscheiden ist die Autorisierung von der Bestimmung der Rechte. Die Autorisierung wird auf vorhanden Rechte gemacht. Die Rechtebestimmung wird in der Anwendung vorgenommen, die Autorisierung der Rechte in dem Autorisierer. Der Autorisierer ist dabei abhängig von der Anwendung, aber nicht anders herum.

Wie ein Recht autorisiert wird ist dem Autorisierer völlig überlassen. Er kann Rechte auf Mitarbeiterebene direkt auf dieser Ebenen autorisieren. Er kann sie aber auch für alle Mitarbeiter autorisieren die eine bestimmte Rolle in der Einrichtung, in einem Team des Mitarbeiter haben, usw.

Um es sich in der Anwendung einfach zu machen, kann man Rechte immer für alle Entitäten bestimmen, die irgendwie betroffen sind. Eine Mitarbeiterrolle lesen oder schreiben zu können kann somit immer von dem Mitarbeier und der Rolle abhängen. Die Autorisierer können dann bestimmen, ob sie das Recht auf Mitarbeiterebene, auf Rollenebene, oder für eine Kombination der beiden vergeben.

Diese Flexibilität in der Rechtevergabe macht die Rechtebestimmung in der Anwendung wesentlich leichter, weil die Anwendung sich keine Gedanken darüber machen muss, wie ein Recht eventuell vergeben werden kann, bzw. wovon es abhängen kann, sondern einfach alles in das Recht rein wirft was vorhanden ist.

So wird es dann auch i.d.R. gemacht werden, weil es erstens auf Ebene der Anwendung einfacher ist, und den Autorisierern viel mehr Flexibilität bietet, wie sie das Recht letzt Enendes vergeben möchten.

Jetzt wird es richtig cool . Die Anwendung, nicht die Autorisierer, kann bestimmen, welche Rechte andere implizieren. Wenn ich z.B. das Leserecht für alle Team Rollen eines Mitarbeiters habe, impliziert dieses Recht das Recht die Kopfdaten der betroffenen Teams lesen zu dürfen. Warum auch nicht? Wenn ich die Kopfdaten dieser Teams in den Mitarbeiter Stammdaten eh lesen darf, warum dann nicht auch an anderen Stellen, z.B. in der Übersicht aller Teams.

Da das Autorisierungs-Framework für jede Rechteanfrage antwortet mit genehmigt, nicht genehmigt und bedingt genehmigt, kann man dem Mitarbeiter in der Liste der Teamrollen anzeigen, dass die Liste u.U. unvollständig ist, weil sie nur bedingt genehmigt ist, falls nur die Teams der Mitarbeiter angezeigt werden, für die der User Leserechte auf die Teamzuordnung hat.

Dabei prüft der Autorisierer immer erst die direkt vergebenen Rechte, danach die implizierten Rechte, weil die direkt vergebenen Rechte meist, wenn nicht immer, einfacher, bzw. schneller genehmigt werden.

Hinweis: Das gehört eigentlich in die Authenfizierung