Hallo zusammen,

ich hätte eine recht allgemeine Frage: wie kann man ein Rechtesystem möglichst performant gestalten?

Folgendes habe ich vor:

• Rechtesystem anhand von Benutzername ODER Gruppenzugehörigkeit
  
• Beispiel: Die Berechtigungen "Darf Settings verwalten" oder "Darf Einträge löschen" sollen sowohl auf Benutzerebene als auch auf Gruppenebene vergeben werden.
  
• Ideal wäre wenn Gruppen ihrerseits auch Mitglieder in anderen Gruppen sein könnten, d.h. das Rechte auch "vererbt" werden
  
• Das Ganze soll später ein REST-Service mit Benutzerauthentifizierung werden, d.h. viele Calls und viele Rechte-Auswertungen

Gedanken dazu:
Bei einem einfachen SELECT auf eine Table kann man ja nicht viel rausholen. Wenn man eine Struktur mit den Tabellen "USER", "GROUP", "PERMISSION" und "MEMBERSHIP" (Zuordnungstabelle mit UserId, GroupId) aufbaut, wird's zwar schon komplexer aber auch da kann man wenig optimieren. Aber wie sieht die Sache aus, wenn Gruppen auch Mitglied anderer Gruppen sein können und ihre Rechte weitervererben? Die SQL-Statements können da ja recht schnell ziemlich komplex werden und sind damit in der Regel auch langsam. Gibt es da "Best Practices" um sowas umzusetzen? Macht es Sinn, dass man allein aus Performance-Gründen eine extra Effective-Permission-Table führt, die die tatsächlichen Berechtigungen widerspiegelt und bei jeder Rechte-Änderung aktualisiert wird? (Bisher ist das mein bester Gedanke um eine möglich gute Performance zu bekommen)

Ich habe aktuell keinen tatsächlichen Fall und baue mir gerade nur ein Projekt im Kopf zusammen... aber generell finde ich solche Design-Überlegungen recht interessant. Einen "optimalen Weg" wird's wahrscheinlich auch hier nicht geben, aber vielleicht gibt es ja interessante Herangehensweisen?

Viele Grüße,
Bruno

Moin und im Forum!

BrunoH hat folgendes geschrieben :

wie kann man ein Rechtesystem möglichst performant gestalten?

Du hast das Wesentliche schon zusammengefasst: entweder "vorausberechnen" (Gruppen-in-Gruppen "flach" rechnen, um die Rekusion zu vermeiden) oder "cachen", viel Anderes gibt´s da nicht.

IBM verfolgt bei Notes sehr konsequent das Caching (da Notes eh schon langsam ist, auch dringend nötig), Microsoft geht den Weg noch etwas weiter und vergibt bei der (Windows-)Anmeldung Access-Tokens, an denen die konkreten Rechte hängen (deshalb kriegt man neue AD-Gruppen auch immer erst mit der nächsten Windows-Anmeldung mit).

Andererseits: mit welchen Workloads rechnest du denn? >10k Access-Request pro Sekunde? Wenn es weniger ist, dann würde ich einfach empfehlen, mal deinem RDBMS zu "vertrauen" und es auszuprobieren. Die Zeiten von MySQL 1.0 sind ja nun auch schon ein paar Tage vorbei...

cu
Narses

Na dann mal ein freundliches Servus zurück

Ok, sowas in der Art dachte ich mir schon, aber manchmal gibt es ja doch auch überraschende Herangehensweisen von Querdenkern, die plötzlich viel schneller und besser funktionieren und man selbst kommt nie auf sowas Gelegentlich bin ich auch schon über Single-Table-Lösungen gestolpert wo User, Gruppen und Rechte in einer einzigen Table zusammengequetscht wurden und vermutlich über Self-Join ausgewertet wurden. Mir war das nur immer zu suspekt um es auch so zu machen (widerspricht ja jeder Norm)

Ehrlichgesagt hab ich noch keinerlei Zahlen, aber nachdem es eine LAN-Application werden soll rechne ich mit weit unter 10k calls/sec, möchte dafür aber mit etwas komplexeren Gruppenstrukturen arbeiten... naja und wenn ich schon was anfange, dann soll's ja auch performant arbeiten

Vielen Dank jedenfalls für's Feedback... ich denke das "flach rechnen" wird vermutlich der Way-To-Go werden auch wenn es mehr Aufwand im Vergleich zum Caching ist, aber für mein Vorhaben überwiegen da die Vorteile

Zu dem Thema passt das wohl ganz gut: de.wikipedia.org/wik...k)#Materialized_View

Zitat:

Ok, sowas in der Art dachte ich mir schon, aber manchmal gibt es ja doch auch überraschende Herangehensweisen von Querdenkern, die plötzlich viel schneller und besser funktionieren und man selbst kommt nie auf sowas Gelegentlich bin ich auch schon über Single-Table-Lösungen gestolpert wo User, Gruppen und Rechte in einer einzigen Table zusammengequetscht wurden und vermutlich über Self-Join ausgewertet wurden. Mir war das nur immer zu suspekt um es auch so zu machen (widerspricht ja jeder Norm)

Quergedacht würde ich mich fragen warum du Rechte überhaupt in eine relationale Datenbank packen willst. Warum nicht irgendeinen Verzeichnisdienst (unter Windows z.B Active Directory) der genau für sowas gedacht ist? Deine Punkteliste deutet nichts an was eine Rechte oder Userverwaltung nahe an den Daten erfordert. Also z.B. irgendwelche Rechte auf direkter Datensatzebene.

Blup hat folgendes geschrieben :

Zu dem Thema passt das wohl ganz gut: de.wikipedia.org/wik...k)#Materialized_View

Ja genau, sowas in der Richtung... gut zu wissen, dass es dafür auch einen Namen gibt

Ralf Jansen hat folgendes geschrieben :

Quergedacht würde ich mich fragen warum du Rechte überhaupt in eine relationale Datenbank packen willst. Warum nicht irgendeinen Verzeichnisdienst (unter Windows z.B Active Directory) der genau für sowas gedacht ist? Deine Punkteliste deutet nichts an was eine Rechte oder Userverwaltung nahe an den Daten erfordert. Also z.B. irgendwelche Rechte auf direkter Datensatzebene.

Ok, ich hab das wirklich sehr allgemein formuliert. Kann man Directory Services in einer eigenen Applikation nutzen für die Rechtevergabe? Also z.B. "Benutzer X darf den Register 'Einstellungen' sehen" oder "Benutzer X darf keine Daten exportieren"?

Moin!

BrunoH hat folgendes geschrieben :

Kann man Directory Services in einer eigenen Applikation nutzen für die Rechtevergabe? Also z.B. "Benutzer X darf den Register 'Einstellungen' sehen" oder "Benutzer X darf keine Daten exportieren"?

Man kann Gruppenzugehörigkeiten prüfen, was du dann damit dem Ergebnis machst, ist doch deine Sache... (und hier käme dann trotzdem wieder der Cache in´s Spiel, sonst dürfte das exponentiell steigende Requests auf dem AD/LDAP bedeuten )

cu
Narses