Best practice: Benutzerverwaltung mit Datenbankanbindung

[Morphie]

Ach was wäre die Welt langweilig, wenn Embarcadero für solche Zwecke mal ein gescheites Framework / gescheite Assistenten mitliefern würde...
Jetzt habe ich jedenfalls erst mal ne Menge Lesestoff, mit dem ich mich beschäftigen kann

Danke DataCool

Zitat von mjustin:

Warum nicht einfach Benutzer -> Rolle (eine oder mehrere) -> Rechte? Dann kann man immer noch besondere Benutzer definieren, die mehr Rechte haben (Admin). Ist natürlioch Geschmackssache, ob man neben Gruppen auch Benutzer einzeln verwalten möchte.

Bei mir sieht es sogar noch ein wenig anders aus

Benutzer
Gruppe
Mandant

Ein Benutzer kann zugriff auf mehrere Mandanten haben
Eine Gruppe kann ebenfalls zugriff auf mehrere Mandanten haben
Ein Benutzer kann in mehreren Gruppen sein

Der Gruppe werden pro Mandant eigene Rechte gegeben
Dem Benutzer werden pro Mandant ebenfalls eigene Rechte gegeben
Ein "Recht" kann drei Zustände annehmen: Erlaubt / Verweigert / Unbekannt (NULL)
Verweigerung hat Vorrang vor Erlaubnis

Zusätzlich hat ein Benutzer dann noch für jeden Mandanten andere "Einstellungen", die ebenfalls gespeichert werden müssen...

Im Prinzip funktioniert es wie die NTFS-Berechtigungen...

[Stevie]

Zitat von mjustin:

Neben dem Anbinden von Rechten an GUI Elemente wünsche ich mir ein Delphi eine Möglichkeit sie über Attribute an Methoden zu binden, so wie es das Apache Shiro Framework kann. Dann könnte man in beliebigen Anwendungsarten (Kommandozeile, Service, Webanwendung) unmittelbar auf Ebene der Geschäftslogik die Rechte prüfen, anstatt in der Visualisierungsschicht.

Mit method interception geht das.

Allerdings hat das den Nachteil, dass man nicht in der GUI sieht, ob man die Aktion durchführen kann, sondern es kommt erst beim Versuch eine Meldung, dass es nicht geht.

Bei einem RAD Ansatz würde ich wahrscheinlich eher eine eigene TAction Klasse bauen, der man Entsprechende Eigenschaften verpassen kann.

[mjustin]

Zitat von Morphie:

Verweigerung hat Vorrang vor Erlaubnis

Zusätzlich hat ein Benutzer dann noch für jeden Mandanten andere "Einstellungen", die ebenfalls gespeichert werden müssen...

Im Prinzip funktioniert es wie die NTFS-Berechtigungen...

Was ist, wenn ein Benutzer sowohl der "Administrator" Gruppe angehört als auch "Gast oder "Praktikant"? Gehen ihm dann seine Admin-Rechte, soweit die dort auf "DENY" stehen, wieder verloren? Oder kommt hier noch eine Art von Hierarchie oder Reihenfolge (geordnete ACL, und das erste darin gefundene Recht oder Deny "gewinnt") ins Spiel? (Siehe http://security.stackexchange.com/qu...access-dilemma)

[Morphie]

Die Rechte gehen ihm dann verloren.
Allerdings macht es keinen Sinn, einen Administrator in die Gruppe "Praktikaten" zu stecken
Es macht auch keinen Sinn, administrative Aufgaben bei den Praktikaten auf Deny zu stellen. Es gibt wie gesagt auch noch das Recht "NULL / Unbekannt / Unbelegt".

Hat ein Benutzer das Recht in keiner seiner Gruppen und auch in der eigenen Rechteverwaltung nicht, dann hat er diese Berechtigung tatsächlich nicht... (Die Berechtigung steht in allen Gruppen auf NULL)
Wenn in irgendeiner Gruppe ein DENY auftaucht, hat der Benutzer ebenfalls keine Berechtigung auf die Funktion, obwohl diese eventuell in einer anderen Gruppe erlaubt ist.
Wenn die Berechtigung in allen anderen Gruppen auf NULL steht, außer in einer (oder mehreren) auf ALLOW, dann hat er die Berechtigung.

Unsere Standardkonfiguration:
Alle Benutzeraufgaben stehen in der Gruppe "Benutzer" auf ALLOW.
Alle Administrativen Aufgaben stehen in der Gruppe "Administrator" auf ALLOW
Die Gruppen Praktikaten, Gast, Auszubildende usw. sind entsprechend mit DENY eingeschränkt

Der Administrator ist in den Gruppen "Benutzer" und "Administratoren"

Trotzdem gibt es noch die Möglichkeit, einzelnen Benutzern bestimmte Rechte wegzunehmen. Oder einem nicht-Administrator eine administrative Aufgabe zuzuteilen...


edit: Natürlich sichern wir uns aber auch entsprechend ab Es gibt immer ein Administrator-Account, der vollzugriff hat. Sonst ständen wir wohl beim Support das eine oder andere Mal doof da

[p80286]

Zitat von Morphie:

Allerdings macht es keinen Sinn, einen Administrator in die Gruppe "Praktikaten" zu stecken

Wenn jemand in der Gruppe "Praktikanten" Mitglied ist, ist er Praktikant!
Warum ist es so selten, das Gruppen nach Funktionen definiert werden?
Immer wieder bei diesen Diskussionen beschleicht mich das Gefühl, daß das Recht irgendetwas zu machen, wie ein Sternchen auf der Schulter ist.
Definiert die Aufgaben, fasst sie in Gruppen zusammen und stopft die Benutzer in die entsprechenden Gruppen.
Feierabend.

Gruß
K-H

[ConstantGardener]

...schau dir auch mal das ORM Aurelius von TMS und den zugehörigen DataModeler an. Der setzt deine Datenbankstruktur direkt in Aurelius-Klassen um.

cu CG