Benutzerrollen, Rechte

[Der schöne Günther]

"You must be at least this tall to edit this property"

So oder ähnlich.


Folgende Geschichte: Meine Anwendung hat nicht den Benutzer, sondern verschiedene Rollen. Der eine kann mehr, der andere weniger. Das haut hier niemanden mehr vom Hocker. Eine Einschränkung jedoch im Vorhinein: Ich habe weder genug Gehirnmasse noch Zeit um eine vernünftige ACL (wie man es von Dateisystemen wie NTFS kennt) umzusetzen. Ich dachte daran, Benutzerrollen nach einer numerischen Größe sortierbar zu machen.

Beispiel:

Code:

root = 100
support = 90
kundeMainteance = 50
kundeQualified = 30
kundeStandard = 10

Gerne auch mit

Delphi-Quellcode:

5..1

für weniger große Zahlen.

Was bringt mir nun diese Sortierung? Ich dachte daran, allen einstellbaren Properties einer Klasse ein Security-Attribut mit den Eigenschaften

Delphi-Quellcode:

canView

und

Delphi-Quellcode:

canEdit

mitzugeben.

Ein im Alltag wenig interessantes Heizgedöns hätte ein

Delphi-Quellcode:

canRead=30

und

Delphi-Quellcode:

canEdit=50

: Erst der Schichtführer und alle "darüber" können nachsehen, wie es denn mit solchen Werten steht, der normale Bediener bekommt diesen Wert nie zu sehen. Die Heizung stärker befeuern oder drosseln kann nur jemand mit einem "Score" von mindestens 50.

Meine Frage:
Wie speichere ich nun am besten, wer was tun kann? Ich sehe drei Möglichkeiten:

1. Ich gebe den Objekt-Properties über Attribute ihre beiden minimal nötigen Werte für canView und canEdit mit. Hier könnte schon einmal stören, dass alle Instanzen nun immer auf die gleichen Werte festgenagelt sind aber damit kann ich leben.
   
   
2. Ich lege eine Tabelle an in welcher ich für jeden Benutzer explizit eine Rechte aufführe: Beispielsweise sage ich "kundeStandard - kann nicht - ändern - TMeineKlasse.meineProperty". Weiterführend könnte ich sogar sagen "kundeQualified - kann - ändern - TMeineKlasse.meineProperty - MINDESTENS 10% - HÖCHSTENS 90%".
   
   
3. Eine Kombination aus beiden: Mittels Attributen im Quelltext lege ich fest, was gängige Benutzerrechte sind und wenn es abgeändert werden muss können die Standardwerte durch eine Datenbank überschrieben werden.

Die Nachteile der drei Möglichkeiten die ich sehe sind folgende:

1. Erlaubt eben nicht mehr als Verstecken und Sperren. Keine Kunsstücke wie dass der Kundenadministrator in einem kleineren Intervall Werte ändern darf als bsp. unser Support.
   
   
2. Fehler und unerwartetes Verhalten ist vorprogrammiert wenn bei der Installation ein paar Zeilen in der Datenbank unter den Tisch fallen. Möchte ich einen neuen Benutzer "zwischen" zwei existierenden Rollen hinzufügen, muss ich wieder alles explizit in der Datenbank festlegen. Füge ich neue Klassen hinzu, muss ich diese auch in die Datenbank aufnehmen. Horror.
   
   
3. Natürlich wieder auf aufwändigsten zu realisieren

Ich habe so etwas in der Richtung noch nie gemacht und kann es nicht mehr länger aufschieben. Außer Panik im Kleinhirn sind hierzu noch nicht viele Gedanken entstanden. Bin ich vielleicht jetzt schon auf dem falschen Dampfer? Oder könnte man es so durchziehen?

[jobo]

Was Dir vorschwebt, haben wir in umgekehrter Form in einem Projekt als UserSkill implementiert. Das Recht selbst hat einen (vom Kunden) definierten Skillwert, der User einen initialen, der vom Kunden (oder wie auch immer automatisch nach gewisser Zeit) erhöht/geändert werden kann.
Das ist noch mit anderen Möglichkeiten kombiniert (z.B. "eigenes Passwort eingeben" - zum Aufwachen)
Das ganze System kann (vom Kunden!) beliebig komplex gestaltet werden.
Auf Clientseite ist das in den Basisklassen fest verankert und muss nicht geändert werden bei neuen / anderen Inhalten.
Für harte Rechte, also SQL Rollen/-Rechte haben wir das je Maske / Datenquelle ebenfalls in einer Basisklasse gekapselt, allerdings nicht auf Feldebene.
Zusätzlich gibt es eine Klasse für clientseitige "Sonderrechte" (z.B. "kann das Drucken" oder "..importieren.."). Sie prüft über DB seitige Definitionen, ob eine bestimmte Funktion ausgeführt werden darf. Da das Sonderrecht idR. mit einer ausprogrammierten Klasse im Client einhergeht, wird das hier gezielt abgefragt und ist so auch kein nennenswerter Zusatzaufwand.

Zu Deiner Idee:
Ich würde sagen, erstmal ok, aber ich stelle mir vor, dass in der Praxis kein User in einer unternehmesweiten "Fachlichkeit" überall einen bestimmten/gleichen Level hat/ erreicht.
Du bekommst also irgendwann Probleme, weil der Müller (der König aus dem Lager), die Feinheiten in der Produktion justiert...

[BUG]

Würde Lösung 2 entsprechen:
Packe die Rechteverwaltung in ein Filter für die entsprechenden Objekte, das die Aufrufe filtert und im Verletzungsfall eine Exception wirft. Der "Nutzer" bekommt die geschützten Objekte aus einer Factory, die passenden Filter (evtl. mehrere) entsprechend seiner Rolle(n) erstellt.
Die Filter selbst können beliebig komplexe Einschränkungen überprüfen und ihre Eigenschaften (z.B. die möglichen Intervallwerte) könnten aus der Datenbank oder aus den Attributen (entsprechend Lösung 1) gelesen werden.

[Union]

Wir haben hier auch Lösung 2 implementiert:

• Benutzer
• Benutzergruppen
• Benutzerberechtigungen
• Gruppenberechtigungen
• Benutzergruppenmitgliedschaften
• Gruppenmitgliedschaften

Dazu eine abgeleitete Actionlist mit entsprechendem erweiterten Property-Editor und ein kleiner Dialog zur Verwaltung der Benutzer, Gruppen und Mitgliedschaften. Das kannst Du natürlich auch genauso gut in einem anderen Basisobjekt regeln, es muss ja nur die ID der Berechtigung gespeichert werden. Damit ist dann fast jede Kombination möglich, ähnlich wie bei den Windows-Berechtigungen.

[p80286]

Wenn Du eine spielerische Lösung suchst würde ich mit Bitmustern arbeiten, ähnlich den Attributen von Dateinen. Mit 32 Eigenschaften kann man immerhin ne Menge erschlagen.
Die "große" Lösung wäre die Speicherung in der Datenbank, da kann der Kunde sich zu Tode konfigurieren, Du mußt nur nachschauen ob für die gewünschte Funktionalität auch eine Berechtigung vergeben wurde. Vielleicht noch ein paar Häkchen a la der admin darf Lesen und Schreiben und Briefe versenden, die die notwendigen Werte im Hintergrund setzen und gut ist. Bitte nicht vergessen, richtige DBs habe noch eine eigene Rechteverwaltung im Rucksack, die muß ggf. mit angepasst werden.

Gruß
K-H

[Der schöne Günther]

Vielen Dank schon einmal für die schnellen Antworten! 8-) :thumb:

Zitat:

Zitat von jobo (Beitrag 1223553)

Das Recht selbst

Das ist schonmal ein interessanter Ansatz. Es ist eigentlich perfekt für Aktionen die ausgeführt werden sollen wie "Drucke einen Report" oder "Pausiere die menscheneinsaugende Turbine". Ich dachte allerdings größtenteils an Settings, also reine Werte anzeigen und ggf. Editieren.
Ich verstehe nicht, was

Zitat:

Zitat von jobo (Beitrag 1223553)

Auf Clientseite ist das in den Basisklassen fest verankert und muss nicht geändert werden bei neuen / anderen Inhalten

genau beudetet. Ich müsste doch trotzdem ständig manuell nach einem passenden Recht suchen, schauen wie es um den aktuellen Nutzer bestellt ist und dementsprechend handeln. Wenn ich eine Klasse nun um neue Properties erweitere, muss ich doch auch ebenso viele neue Rechte hinzudichten? Oder habe ich was falsch verstanden?

Zitat:

Zitat von jobo (Beitrag 1223553)

in der Praxis kein User in einer unternehmesweiten "Fachlichkeit" überall einen bestimmten/gleichen Level hat/ erreicht.
Du bekommst also irgendwann Probleme, weil der Müller (der König aus dem Lager), die Feinheiten in der Produktion justiert...

Das stimmt, daran habe ich noch nicht gedacht. Die Software ist allerdings recht speziell, so unterschiedliche Qualifikationen sollten da nicht auftreten. Zumindest noch nicht...

Zitat:

Zitat von BUG (Beitrag 1223554)

Packe die Rechteverwaltung in ein Filter für die entsprechenden Objekte, das die Aufrufe filtert und im Verletzungsfall eine Exception wirft. Der "Nutzer" bekommt die geschützten Objekte aus einer Factory, die passenden Filter (evtl. mehrere) entsprechend seiner Rolle(n) erstellt.

Aber entweder müsste ich den Quellcode dieser Filterfabrik jedes mal anpassen, wenn sich an den Objekten etwas ändert, oder ich das Ding ist so flexibel, dass es Getter und Setter dynamisch zusammenbaut. Ein ganz schönes Monsterteil.

Zitat:

Zitat von Union (Beitrag 1223556)

[...]

Das wäre mit Sicherheit die feine englische Art. Aber Benutzer in Gruppen stecken, Benutzerrechte überschreiben evtl. wieder Gruppenrechte, Benutzer in mehreren Gruppen - Das bekomme ich in gefordertet Zeit niemals hin, ich muss bei etwas einfacherem bleiben :pale:

Zitat:

Zitat von p80286 (Beitrag 1223559)

Die "große" Lösung wäre die Speicherung in der Datenbank, da kann der Kunde sich zu Tode konfigurieren, Du mußt nur nachschauen ob für die gewünschte Funktionalität auch eine Berechtigung vergeben wurde.

Gerade das Nachschauen sieht für mich aus wie Gewitterwolken am Horizont. An den Objekten selbst wird sich über die nächste Zeit viel ändern, das kann ich riechen. Dieses Nachschauen möchte ich nicht manuell machen. Der Kunde bekommt eine neue Softwareversion, die Objekte haben etliche neue Properties, seine Config-Datenbank bleibt natürlich unangetastet. Jetzt haben alle neuen Dinge ein Default-Verhalten, bsp. von jedem les- und schreibbar.


Bonus:
Man sollte noch ausführen, dass die Anwendung aus mehreren, miteinander kommunizierenden Prozessen besteht. Im Endeffekt ist es eine Master-Anwendung (inkl. grafisches Frontend) mit mehreren Slave-Prozessen, die nur auf Anfragen antworten und nicht von sich aus sprechen. Aus diesen Prozessen möchte ich Werte auslesen und ggf. setzen. Und diese Prozesse sollen sich auch nicht mit Datenbanken herumschlagen.
Deshalb war (und ist) es mir immer noch sehr sympathisch, per Attribute im Quelltext standardmäßige Berechtigungswerte vorzugeben, der Benutzer soll das in der Master-Anwendung anpassen können.

[jobo]

Zitat:

Zitat von Der schöne Günther (Beitrag 1223565)

Ich verstehe nicht, was

Zitat:

Zitat von jobo (Beitrag 1223553)

Auf Clientseite ist das in den Basisklassen fest verankert und muss nicht geändert werden bei neuen / anderen Inhalten

genau beudetet. Ich müsste doch trotzdem ständig manuell nach einem passenden Recht suchen, schauen wie es um den aktuellen Nutzer bestellt ist und dementsprechend handeln. Wenn ich eine Klasse nun um neue Properties erweitere, muss ich doch auch ebenso viele neue Rechte hinzudichten? Oder habe ich was falsch verstanden?

Bei dem Abschnitt handelt es sich um das Skillsystem, es ist nicht bindend in der Anwendung, nur eben sehr vergleichbar zu Deinem (und halt umgekehrt).
Jede darstellbare/bearbeitbare Maske~Datenquelle kommt mit einer eindeutigen ID aus der DB (dynamisch). Die Datenzugriffsklassen erfragen nun per se den minimal geforderten Skill und den des Users. Unzureichende UserSkills werden schon von serverseite gar nicht ausgeliefert, was übrigbleibt (UserSkill höher als erforderlicher Maskenskill) wird auf Details geprüft.
Die Basisklasse braucht immer nur 3 Parameter zu prüfen (ID, Userskill~istwert, VorgabeSkill~minimaler Sollwert). Da muss nichts nachgepflegt werden, außer die Maske bietet eine Spezialfunktion, zu der es eine Skillregel gibt. Wie gesagt, die "Clientspezialfunktion" erfordert sowieso ein individuelle Implementierung, da tut die individuelle Skillabfrage nicht weh.

Zu Deiner letzten Anmerkung: Dein System müsste dann alle in Frage kommenden Berechtigungsfälle des Subsystems abfragen (die also kennen oder "besorgen" können) und ihm die Resultate mitgeben, damit dieses dann autark arbeiten kann.

[p80286]

Zitat:

Zitat von Der schöne Günther (Beitrag 1223565)

Gerade das Nachschauen sieht für mich aus wie Gewitterwolken am Horizont. An den Objekten selbst wird sich über die nächste Zeit viel ändern, das kann ich riechen. Dieses Nachschauen möchte ich nicht manuell machen.
Der Kunde bekommt eine neue Softwareversion, die Objekte haben etliche neue Properties, seine Config-Datenbank bleibt natürlich unangetastet. Jetzt haben alle neuen Dinge ein Default-Verhalten, bsp. von jedem les- und schreibbar.

Naja das ist doch ganz hübsch, nur wo ist das Problem des Nachschauens? für jede Funktionalität hast Du im allg. auch einen Namen dazu packst Du eine Berechtigung und einen Benutzer( und/oder eine Rolle) fettich.

Das mit dem "Config-Datenbank bleibt natürlich unangetastet" passt mir nicht, das klingt wie wasch mich aber mach mich nicht naß. Du Ihr sollt also beliebig komplexe Berechtigungsmodelle in Source gießen, und 2 Wochen nach Auslieferung steht der Kunde weinend auf der Matte und erzählt "so hab ich es aber nicht gemeint!"

Gruß
K-H

[Union]

Zitat:

Zitat von Der schöne Günther (Beitrag 1223565)

Zitat:

Zitat von Union (Beitrag 1223556)

[...]

Das wäre mit Sicherheit die feine englische Art. Aber Benutzer in Gruppen stecken, Benutzerrechte überschreiben evtl. wieder Gruppenrechte, Benutzer in mehreren Gruppen - Das bekomme ich in gefordertet Zeit niemals hin, ich muss bei etwas einfacherem bleiben :pale:

So problematisch ist das nicht. Das basiert dann auf einer einzigen SQL-Abfrage:

Code:

select us.name,
      userrights.Rightid as UsRId,
      Grouprights.Rightid as GRRId,
      r1.Nr as UsRNr,
      r2.Nr as GrRNr
from "user" as us
left outer join userrights on userrights.userid = us.id
left outer join usergroups on usergroups.userid = us.id
left outer join grouprights on grouprights.groupid = usergroups.groupid
left outer join Rights r1 on r1.id = Userrights.rightid
left outer join Rights r2 on r2.id = Grouprights.rightid
where ucase(us.name) = :username
and r1.nr = :nr or r2.nr = :nr

Wenn diese Query etwas zurückgibt, hat der Benutzer :username die Berechtigung für :nr.

[CarlAshnikov]

Auch für mich ein sehr interessantes Thema. Habe leider inhaltlich nichts beizusteuern. :(

@Union könntest du deinen Ansatz mit der Actionlist etwas genauer erläutern? Ich denke mal, dass du so die Controls mit den entsprechenden Berechtigungen verbindest? Ich hoffe das führt hier nicht am Thema vorbei.