Modellierung - Benutzer/Gruppen

[OlliL]

Hallo zusammen,

vorweg erstmal sorry für die WoT, aber ich hoffe das doch jemand weiter liest...

Ich habe eine kleine Anwendung, welche ursprünglich nur "Benutzer" kannte. Irgendwann kam dann der Umstand hinzu, das Ich zu meinen "Benutzern" auch noch "Gruppen" brauchte um bestimmte Berechtigungskonzepte abzubilden.

Es sieht heute also aktuell so aus, das ich Entitäten habe, welche immer auch eine UserID enthalten.
Dazu gibt es dann aber auch eine Benutzer-Gruppen Beziehungsentität welche wiederum den Gruppen Bezug abbildet.

In den fachlichen Modulen welche nun die jeweiligen Tabellen verwenden, ist implementiert was jemand machen darf, dem der Datensatz gehört, und was jemand machen darf, der nur über die Gruppe das Recht auf diesen Datensatz hat. Zur Vereinfachung des Zugriffes gibt es zu jeder Entität eine View welche die Rohdaten mit der user-Gruppen-Tabelle joint und darüber jeweils immer die User-ID des Zugreifers zurückliefert aber auch die ID des eigentlichen Erzeugers des Satzes.

Das reichte dann aber teilweise auch nicht, so das es dazu kam, das in einer Tabelle z.B. ein "privat" flag eingeführt wurde was nun dieses Standardhandling (jedes Gruppenmitglied darf alles von anderen Gruppenmitgliedern sehen) wieder überschreibt.

Alles in allem eine Situation die mir aktuell so nicht mehr gefällt, und nach einem Refactoring schreit.

Ich habe mir nun folgendes vorgestellt, und würde dies gerne zur Diskussion stellen:

• Benutzer und Gruppen werden nun in der gleichen Entität gepflegt, und bedienen sich dem gleichen ID-Pool, sind somit datenbankseitig absolut gleichwertig. Über einer Parent-Child-Verknüpfung sind diese miteinander verknüpft

+--------+--------+-----------+
| id     | name   | parent_id |
+--------+--------+-----------+
| 0      | Master | NULL      |
+--------+--------+-----------+
| 1      | Grp1   | 0         |
+--------+--------+-----------+
| 2      | User1  | 1         |
+--------+--------+-----------+
| 3      | User2  | 1         |
+--------+--------+-----------+

• Jede Entität bekommt nun zwei neue ID-Felder. Eine ID die auf dem tiefsten Level (User) welche aussagt wer der "Erzeuger" dieses Datensatzes ist, und ein Feld welches den "Zugreifer" auf diesen Datensatz angibt.
• Für den "Erzeuger" gilt nach wie vor die Regel:
  • nur er darf den von ihn angelegten Datensatz ändern und sehen
• Für den "Zugreifer" gilt:
  • auch er darf diesen Datensatz sehen, aber niemals ändern
• Ist der Datensatz, dem "Zugreifer" der ID 1 zugeordnet, und wurde von ID 2 erzeugt, darf jeder aus der "Gruppe" ID 1 diesen Datensatz sehen, aber nur ID 2 darf ihn modifizieren
• Möchte ID 2, das dieser Datensatz "privat" ist, also ihn auch kein anderer sehen darf, wird der Datensatz automatisch beim "Zugreifer" auch auf ID 2 gesetzt. Es gibt also kein "privat" flag mehr.

 

[akretschmer]

Alles in allem eine Situation die mir aktuell so nicht mehr gefällt, und nach einem Refactoring schreit.

Mit welcher DB arbeitest Du?

Mir scheint, Du bildest die Sicherheitsstruktur in der Applikation ab, oder? Das geht auch in der DB, hier mal zwei Links als Ansatz: http://veil.projects.pgfoundry.org/curdocs/ und http://wiki.postgresql.org/wiki/SEPostgreSQL_Introduction

Nein, Erfahrung habe ich damit selber nicht.

 

[OlliL]

Ich verwende MySQL.

Ich will jedoch die Logik komplett in der Applikation haben, und möglichst wenig in der DB. Im Grunde möchte ich die DB nur als Persistenzschicht betrachten, noch existierende Stored Procedures und Functions will ich "ausklingen" lassen und in die Applikation verschieben.

Veil scheint mir auf den ersten Blick sowas wie in Richtung Oracles Row Level Security zu sein... Es arbeitet auch mit views, was dann wiederum zu anderen Problemen führen kann, Stichwort Java und Hibernate.

 

[akretschmer]

Ich will jedoch die Logik komplett in der Applikation haben, und möglichst wenig in der DB. Im Grunde möchte ich die DB nur als Persistenzschicht betrachten, noch existierende Stored Procedures und Functions will ich "ausklingen" lassen und in die Applikation verschieben.

Hat dies einen nachvollziehbaren Grund?

Der Vorteil von solchen Dingen wie Stored Procs ist ja grad eben, daß diese 'nah' an den Daten sind - und damit sehr wahrscheinlich schneller mit diesen hantieren können als z.B. PHP.

 

[OlliL]

Jup, Anwendungslogik an einer Stelle und nicht an mehreren.
Dank Caching von Objekten ist das Performancethema auch nicht so kritisch.
Aber eigentlich will ich nicht über SPs, UDFs und deren Sinnhaftigkeit diskutieren, sondern über meine Idee bzgl. Userhandling

 

[Hony%]

Hi.

Ich hab da ein paar Fragen zu deiner Idee die ich aus deinem Text nicht herauslesen konnte:

1. Kann ein Benutzer auch in einer zweiten Gruppe sein?
2. Wird das System auch für andere Dinge als die Sichtbarkeit benutzt?

Wenn nein kann deine Idee meiner Meinung nach gut funktionieren. Allerdings sehe ich keine Möglichkeit Sonderrechte wie die eines Administrators abzubilden. Aber auch spätere Änderungen könnten sich als schwierig oder sogar unmöglich erweisen.

 

[OlliL]

Hi,

nach aktuellem Stand kann ein Benutzer nur in einer Gruppe sein. Wenn Benutzer chaotisch in mehreren Gruppen sein könnten, klappt das natürlich nicht so wie von mir geplant... mhhhh.
Wie beschrieben, wird einerseits geregelt wer was sehen/verwenden darf, aber auch wer was editieren darf (immer nur der Erzeuger von Daten).
So etwas wie einen Admin gibt es, das ist heute ein spezielles Recht an einem Benutzer (könnte über dieses System dann aber auch an einer Gruppe hängen usw.). Es dient aber nur dazu den Anwender zu berechtigen Systemeinstellungen vorzunehmen. So etwas wie einen "einer darf alles sehen und editieren"-User gibt es nicht und darf es auch nicht geben.