Benutzerverwaltung Client-Server Datenbank

[elmar.faber]

Vielen Dank für die vielen Anregungen, ich denke es kristallisiert sich die Lösung der Zwischenschicht
heraus, so wie befürchtet, was allerdings bei max. 80 Benutzern meiner Meinung nach den Aufwand gegenüber
dem Nutzen deutlich sprengt. Da wäre doch eine eigene Instanz im Cluster deutlich sinnvoller.
Ich finde auch, wie hier mehrfach angesprochen wurde, eine Lösung mit einem Benutzer der dazu noch owner
sein müßte bzw. zu hohe Rechte benötigt, viel zu kritisch in Punkto Sicherheit. Um aber Rollen anzupassen
brauche ich nunmal gewisse Rechte. Ausserdem wüßte ich nicht, wie ich in einer laufenden Session Benutzerrechte
anpassen könnte - würde dann nicht der nächste Benutzer auch diese Rechte erst einmal haben und wieder verändern?
Hat von euch schon mal jemand ein Projekt mit einer Zwischenschicht umgesetzt oder Informationen wie man sowas
umsetzen könnte (Gibt es vielleicht irgendwo ein einfaches Beispiel um mal die prinzipielle Vorgehensweise zu sehen?

Viele Grüße

[jobo]

Zitat von elmar.faber:

Um aber Rollen anzupassen
brauche ich nunmal gewisse Rechte. Ausserdem wüßte ich nicht, wie ich in einer laufenden Session Benutzerrechte
anpassen könnte

Nochmal zum Sortieren:
Die Rollengeschichte, die ich ins Spiel gebracht habe, geht nicht unter MS SQL. Zumindest nicht so, wie ich dachte. Ich dachte die hätten da was von Oracle übernommen. In Oracle ist es nur ein SQL Befehl, der auf die entsprechend vordefinierte(n) Rolle(n) umschaltet.
Zwischenschicht: Wenn Du sie clientseitig implementierst, ändert es nichts daran, dass die DB mit einem zentralen User für alle da steht. Klassisch ist eine Zwischenschicht serverseitig angelegt und hat als einzige physikalisch Zugriff auf die DB.
"Instanz": Ich weiß nicht, ob wir da nur Begriffsprobleme haben, aber eine eigene Instanz sollte nicht notwendig sein. Das sollte doch gehen mit SQL Server, vielleicht kann das jemand bestätigen:
Nur eine eigene DB. Eine eigene DB sollte administrativ autark zu verwalten sein. Ein entsprechender User darf nur dort weitere User anlegen und löschen, Rollen dürften ebenfalls nur mit Berechtigungen für Tabellen dieser DB angelegt und vergeben werden.
Und noch als Idee: Wenn für das Anlegen und Löschen eine eigenständige SP gebaut wird, die nur selbst angelegte User auch wieder löschen kann und der User, der diese SP administrativ nutzt, selbst keine anlegen darf, könnte man auch mit dem bestehenden System klarkommen.

[Lemmy]

Zitat von elmar.faber:

Vielen Dank für die vielen Anregungen, ich denke es kristallisiert sich die Lösung der Zwischenschicht
heraus, so wie befürchtet, was allerdings bei max. 80 Benutzern meiner Meinung nach den Aufwand gegenüber
dem Nutzen deutlich sprengt.

vielleicht verrennst Du dich da gerade in irgend welchen monströsen Dingen...

Zitat von elmar.faber:

Ich finde auch, wie hier mehrfach angesprochen wurde, eine Lösung mit einem Benutzer der dazu noch owner
sein müßte bzw. zu hohe Rechte benötigt, viel zu kritisch in Punkto Sicherheit.

Ich habe jetzt nicht jeden Beitrag gelesen, meine aber, dass das so explizit nirgends stand. Es geht darum, dass Du einen Benutzer für die Datenbankzugriffe verwendest, das muss nicht der Owner sein (und um es anders zu sagen: Es sollte nicht der DB Owner sein). D.h. du müsstest in der MSSQl-Instanz lediglich 2 User anlegen, keine 80 (was die Coexistenz mit anderen Datenbankanwendungen deutlich erleichtert, außer jeder nimmt die beiden selben User: DBUser und DBAdmin . Der Owner macht Backups, DDL Updates,..., der "einfache" Benutzer dann DML (Insert, Select, Update, Delete). Sollten Fremdsysteme auch Zugriff auf die Daten erhalten wäre ggf. noch ein dritter DBUser notwendig mit entsprechend wengier Rechten (z.B. nur Zugriff auf bestimmte Views)


Und jetzt nochmal zur Zwischenschicht:

Eine Zwischenschicht hast Du eh: Zumindest Datenbankzugriffskomponenten, besser (bei 80 Anwendern auf einer DB würde ich sogar davon ausgehen, dass das Pflicht ist) wäre der Einsatz eines ORM - und genau hier hättest Du dann die Chance ein Zugriffsmanagement recht einfach zu implementieren - nämlich, darf der gerade angemeldete Nutzer der Software diese Daten abrufen / anzeigen / ändern oder eben nicht. Hat aber nix mit dem DBUser zu tun.

Und um das dann noch eine Stufe höher aufzuhängen: Restserver: Der liefert dir die Daten und würde sich auch um die Berechtigung kümmern, was ein bestimmter Nutzer (oder besser seine zugewiesene Gruppenberechtigung) darf und was nicht. Und um den Punkt auch noch abzudecken: Wenn Du für deinen Restserver (solltest Du jemals einen implementieren) auch Anmeldemöglichkeiten für google+, Facebook,... anbieten, hättest Du hier auch keine unterschiedlichen Datenbankuser sondern eben nur "einen", dafür aber eine eigene auf der Anwendungsseite (=Restserver) liegende Rechteverwaltung.

[Fishermans]

Zitat:

vielleicht verrennst Du dich da gerade in irgend welchen monströsen Dingen...

Ja das stimmt wohl, das Gefühl hab ich auch... Ich habe nun so viele Gespräche und Diskussionen geführt, dass ich nicht mehr so recht weiß, wie ich weiter vorgehen soll.

Zitat:

Eine Zwischenschicht hast Du eh: Zumindest Datenbankzugriffskomponenten, besser (bei 80 Anwendern auf einer DB würde ich sogar davon ausgehen, dass das Pflicht ist)

Ist das wirklich als Zwischenschicht zu rechnen? Dann sind doch die Daten schon auf dem Frontend. Das will ich ja vermeiden. Ich habe mich auch unglücklich ausgedrückt, ich habe zwar 80 Benutzer aber maximal 30 Anmeldungen (Schichtdienst).

Zitat:

außer jeder nimmt die beiden selben User: DBUser und DBAdmin . Der Owner macht Backups, DDL Updates,..., der "einfache" Benutzer dann DML (Insert, Select, Update, Delete). Sollten Fremdsysteme auch Zugriff auf die Daten erhalten wäre ggf. noch ein dritter DBUser notwendig mit entsprechend wengier Rechten (z.B. nur Zugriff auf bestimmte Views)

Das höre ich gerne das war eines meiner Vorschläge für einige Rollen "Rollen-Benutzer" anzulegen.

Zitat:

Und um das dann noch eine Stufe höher aufzuhängen: Restserver: Der liefert dir die Daten und würde sich auch um die Berechtigung kümmern, was ein bestimmter Nutzer (oder besser seine zugewiesene Gruppenberechtigung) darf und was nicht. Und um den Punkt auch noch abzudecken: Wenn Du für deinen Restserver (solltest Du jemals einen implementieren) auch Anmeldemöglichkeiten für google+, Facebook,... anbieten, hättest Du hier auch keine unterschiedlichen Datenbankuser sondern eben nur "einen", dafür aber eine eigene auf der Anwendungsseite (=Restserver) liegende Rechteverwaltung.

Das wäre dann genau das was ich brauche, das Problem ist die Einarbeitung in die Thematik und die Umsetzung. Das Projekt ist noch lange nicht abgeschlossen und ständige Veränderungen an der Datenbankstruktur sind notwendig, das wird dann viel komplizierter. Ist "DataSnap" auch für eine Benutzerverwaltung in der Zwischenschicht geeignet? Ich habe dazu kaum Informationen gefunden.
Ich denke, ich sollte mich mit dem spannenden Thema Restserver / DataSnap beschäftigen... das Problem wird sein, die richtigen Informationen zu finden, die Beschreibungen sind ja eher sehr ernüchternd dünn im Netz gesät... Vielleicht gibt es ja dazu auch den ein oder anderen Tipp...

[Lemmy]

Zitat von Fishermans:

Zitat:

Eine Zwischenschicht hast Du eh: Zumindest Datenbankzugriffskomponenten, besser (bei 80 Anwendern auf einer DB würde ich sogar davon ausgehen, dass das Pflicht ist)

Ist das wirklich als Zwischenschicht zu rechnen? Dann sind doch die Daten schon auf dem Frontend. Das will ich ja vermeiden. Ich habe mich auch unglücklich ausgedrückt, ich habe zwar 80 Benutzer aber maximal 30 Anmeldungen (Schichtdienst).

Nach meiner Meinung ja, nur bringt dir die wenig. Ein gekapseltes ORM ist hier deutlich mächtiger (wie ich das Wort hasse) und flexibler. Die 80 Benutzer habe ich jetzt als "Maßstab" genommen, dass es nicht nur eine ToDo-Liste wird. Wenn Du bei Delphi bleibst, schau dir mal 1-2 Tage tiopf an, etwas steile Lernkurve, aber dann kann man gut damit arbeiten.

Zitat:

außer jeder nimmt die beiden selben User: DBUser und DBAdmin . Der Owner macht Backups, DDL Updates,..., der "einfache" Benutzer dann DML (Insert, Select, Update, Delete). Sollten Fremdsysteme auch Zugriff auf die Daten erhalten wäre ggf. noch ein dritter DBUser notwendig mit entsprechend wengier Rechten (z.B. nur Zugriff auf bestimmte Views)

Das höre ich gerne das war eines meiner Vorschläge für einige Rollen "Rollen-Benutzer" anzulegen.

Zitat von Fishermans:

Das wäre dann genau das was ich brauche, das Problem ist die Einarbeitung in die Thematik und die Umsetzung. Das Projekt ist noch lange nicht abgeschlossen und ständige Veränderungen an der Datenbankstruktur sind notwendig, das wird dann viel komplizierter. Ist "DataSnap" auch für eine Benutzerverwaltung in der Zwischenschicht geeignet? Ich habe dazu kaum Informationen gefunden.

wenn ich das auf die schnelle richtig verstehe dann ja. Aber das über einen Appserver/Restserver zu lösen da bedarf es dann schon etwas mehr Anforderungen als eine einfach CRUD-Anwendung.