Benutzerverwaltung Client-Server Datenbank

[mkinzler]

Die "Zwischenschicht" kann auch in Deinem Programm implementiert werden. Die Benutzer müssen dann nicht als Datenbankbenutzer angelegt werden, sondern Dein Programm enscheidet anhand des Benutzers (des Programmes) was dieser darf.

[elmar.faber]

Dann hätte ich aber keine saubere Trennung von Frontend und Backend mehr da ja prinzipiell
alle Daten ins Frontend gelangen und erst da gefiltert wird

[mkinzler]

Jein. Wenn die Rechte fehlen kannst Du ja verhindern, dass die Daten geladen werden.

[elmar.faber]

Ja genau da liegt mein Verständnisproblem, ich baue eine Verbindung zur Datenbank auf und die Rechte
sind fest über einen Benutzer definiert, wie erreiche ich es, dass ein bestimmter Benutzer nur ganz
bestimmte Rechte bekommt? Ich müßte doch hierzu die Verbindung trennen und mit einem Benutzer mit anderen Rechten
wieder neu aufbauen. Wie steuere ich die Rechte für viele Anwender mit nur einem angelegten DB-Benutzer?
Und verhindere gleichzeitig, dass nie Daten das Backend verlassen, zu denen der Anwender keine Rechte besitzt?

[mkinzler]

Die Frage ist ja, ob man das über Datenbankbenutzer regeln muss, oder durch eine Benutzerverwaltung im Programm.

[jobo]

Zitat von elmar.faber:

wie erreiche ich es, dass ein bestimmter Benutzer nur ganz
bestimmte Rechte bekommt?

Das ginge nur, wenn Du dem Benutzer in der geöffneten Session diese Rechte erteilst, also so, wie ich es oben mit der Rolle vorgeschlagen habe.

Zitat von elmar.faber:

Ich müßte doch hierzu die Verbindung trennen und mit einem Benutzer mit anderen Rechten
wieder neu aufbauen.

Nein, nicht unbedingt. Schau Dir mal die Möglichkeiten an, die die role grants bieten.

Zitat von elmar.faber:

Wie steuere ich die Rechte für viele Anwender mit nur einem angelegten DB-Benutzer?

Über wechselnde Rollen oder gar nicht, soweit mir bekannt.

Zitat von elmar.faber:

Und verhindere gleichzeitig, dass nie Daten das Backend verlassen, zu denen der Anwender keine Rechte besitzt?

Wenn Du es so machst, wie es üblich ist (Mehrschichtanwendung) nur durch Sorgfalt.
Alternativ baust Du wie vorgeschlagen eine eigene, anwendungsinterne Zwischenschicht, die anhand logisch zugewiesener Rollen für den jeweiligen User die Zugriffe auf die DB prüft und erlaubt oder verbietet.

[p80286]

Ich sehe die "one User fits all"-Lösung sehr kritisch.
Sobald die Möglichkeit besteht, daß jemand sich die Zugangsdaten des DB-Users besorgt, der dann auch noch Owner ist, dann kann man die Zugangsdaten auch gleich ans schwarze Brett pinnen.

Jeder User der Zugriff auf eine DB hat, sollte nicht mehr Rechte/Möglichkeiten haben als unbedingt nötig.

Gruß
K-H

[jobo]

Zitat von p80286:

Ich sehe die "one User fits all"-Lösung sehr kritisch.
..ans schwarze Brett pinnen.
..nicht mehr Rechte/Möglichkeiten haben als unbedingt nötig.

Ja, das ist letztlich wohl der wichtigste Punkt. In der klassischen Zwischenschicht dringt ja kein User soweit vor.

Ich habe auch selbst noch mal nach der set role Funktion geschaut, aber da findet man nichts bzw. nichts sinnvolles, was so etwas abbildet.
Es ist allerdings schon so, dass man unter einem SQL Server standardmäßig verschiedene DB liegen hat und ansprechen kann, wenn die Rechte passen. Also könntest Du mit dem Owner sicher auch das Recht bekommen, auf dieser DB und nur darauf User anzulegen und zu löschen, wahlweise als Domaine User oder SQL Variante.