scribbled draft for cookie cutter approach (Schema-F) for permissons/roles/grants
This commit is contained in:
parent
528ad42fa6
commit
048551b34b
77
doc/rbac-schema-f.md
Normal file
77
doc/rbac-schema-f.md
Normal file
@ -0,0 +1,77 @@
|
|||||||
|
*(this is just a scribbled draft, that's why it's still in German)*
|
||||||
|
|
||||||
|
### *Schema-F* für Permissions, Rollen und Grants
|
||||||
|
|
||||||
|
Permissions, Rollen und Grants werden in den INSERT/UPDATE/DELETE-Triggern von Geschäftsobjekten erzeugt und gelöscht. Das Löschen erfolgt meistens automatisch über das zugehörige RbacObject, die INSERT- und UPDATE-Trigger müssen jedoch in *pl/pgsql* ausprogrammiert werden.
|
||||||
|
|
||||||
|
Das folgende Schema soll dabei unterstützen, die richtigen Permissions, Rollen und Grants festzulegen.
|
||||||
|
|
||||||
|
An einigen Stellen ist vom *Initiator* die Rede. Als *Initiator* gilt derjenige User, der die Operation (INSERT oder UPDATE) durchführt bzw. dessen primary assumed Rol. (TODO: bisher gibt es nur assumed roles, das Konzept einer primary assumed Role müsste noch eingeführt werden, derzeit nehmen wir dafür immer den `globalAdmin()`. Bevor Kunden aber selbst Objekte anlegen können, muss das geklärt sein.)
|
||||||
|
|
||||||
|
#### Typ Root: Objekte, welche nur eine Spezialisierung bzw. Zusatzdaten für andere Objekte bereitstellen (z.B. Partner für Relationships vom Typ Partner oder Partner Details für Partner)
|
||||||
|
|
||||||
|
Objektorientiert gedacht, enthalten solche Objekte die Zusatzdaten einer Subklasse; die Daten im Partner erweitern also eine Relationship vom Typ `partner`.
|
||||||
|
|
||||||
|
- Dann muss dieses Objekt zeitlich nach dem Objekt erzeugt werden, auf dass es sich bezieht, also z.B. zeitlich nach der Relationship.
|
||||||
|
- Es werden Delete (\*), Edit und View Permissions für dieses Objekt erzeugt.
|
||||||
|
- Es werden **keine** Rollen für dieses Objekt erzeugt.
|
||||||
|
- Statt eigener Rollen werden die o.g. Permissions passenden Rollen des Hauptobjekts zugewiesen (granted) bzw. aus denen entfernt (revoked).
|
||||||
|
- Handelt es sich um Zusatzdaten zum Zwecke der Spezialisierung, dann z.B. so:
|
||||||
|
- Delete (\*) <-- Owner des Hauptobjektes
|
||||||
|
- Edit <-- **Admin** des Hauptobjektes
|
||||||
|
- View <-- Agent des Hauptobjektes
|
||||||
|
- Handelt es sich um Zusatzdaten, für die sich Edit-Rechte delegieren lassen sollen (wie im Falle der Partner-Details eines Partners), dann z.B. so:
|
||||||
|
- Delete (\*) <-- Owner des Hauptobjektes
|
||||||
|
- Edit <-- **Agent** des Hauptobjektes
|
||||||
|
- View <-- Agent des Hauptobjektes
|
||||||
|
|
||||||
|
Anmerkung: Der Typ-Begriff *Root* bezieht sich auf die Rolle im fachlichen Datenmodell. Im Bezug auf den Teilgraphen eines fachlichen Kontexts ist dies auch eine Wurzel im Sinne der Graphentheorie. Aber in anderen fachlichen Kontexten können auch diese Objekte von anderen Teilgraphen referenziert werden und werden dann zum inneren Knoten.
|
||||||
|
|
||||||
|
|
||||||
|
#### Typ Aggregator: Objekte, welche weitere Objekte zusammenfassen (z.B. Relationship fasst zwei Persons und einen Contact zusammen)
|
||||||
|
|
||||||
|
Solche Objekte verweisen üblicherweise auf Objekte vom Typ Leaf und werden oft von Objekten des Typs Root referenziert.
|
||||||
|
|
||||||
|
- Es werden i.d.R. folgende Rollen für diese Objekte erzeugt:
|
||||||
|
- Owner, Admin, Agent, Tenent(, Guest?)
|
||||||
|
- Es werden Delete (\*), Edit und View Permissions für dieses Objekt erzeugt.
|
||||||
|
- Die Permissions werden den Rollen sinnvoll zugewiesen, z.B.:
|
||||||
|
- Owner -> Delete (\*)
|
||||||
|
- Admin --> Edit
|
||||||
|
- Tenant (oder ggf. Guest) --> View
|
||||||
|
- Außerdem werden folgende Grants erstellt bzw. entzogen:
|
||||||
|
- Initiator --> Owner
|
||||||
|
- Owner --> Admin
|
||||||
|
- Admin --> Referrer
|
||||||
|
- Admins der referenzierten Objekte werden Agent des Aggregators
|
||||||
|
- Tenants des Aggregators werden Referrer der referenzierten Objekte
|
||||||
|
|
||||||
|
### Typ Leaf: Handelt es sich um ein Objekt, welches (außer zur Modellierung separater Permissions) keine Unterobjekte enthält (z.B. Person, Customer)?
|
||||||
|
|
||||||
|
Solche Objekte werden üblicherweise von Objekten des Typs Aggregator, manchmal auch von Objekten des Typs Root, referenziert.
|
||||||
|
|
||||||
|
- Es werden i.d.R. folgende Rollen für diese Objekte erzeugt:
|
||||||
|
- Owner, Admin, Referrer
|
||||||
|
- Es werden Delete (\*), Edit und View Permissions für dieses Objekt erzeugt.
|
||||||
|
- Die Permissions werden den Rollen sinnvoll zugewiesen, z.B.:
|
||||||
|
- Delete (\*) <-- Owner
|
||||||
|
- Edit <-- Admin
|
||||||
|
- View <-- Referrer
|
||||||
|
- Außerdem werden folgende Grants erstellt bzw. entzogen:
|
||||||
|
- Owner --> Admin
|
||||||
|
- Admin --> Referrer
|
||||||
|
|
||||||
|
```mermaid
|
||||||
|
flowchart LR
|
||||||
|
|
||||||
|
subgraph partnerDetails
|
||||||
|
direction TB
|
||||||
|
style partnerDetails fill:#eee
|
||||||
|
|
||||||
|
perm:partnerDetails.*{{partnerDetails.*}}
|
||||||
|
role:partnerDetails.edit{{partnerDetails.edit}}
|
||||||
|
role:partnerDetails.view{{partnerDetails.view}}
|
||||||
|
|
||||||
|
|
||||||
|
end
|
||||||
|
```
|
Loading…
Reference in New Issue
Block a user