aus der Java Perspektive gibt es da durchaus gängige Konzepte (mal unabhängig davon, was man im einzelnen davon hält). Zugriffsregeln wandern in die Applikation, alleine schon aus Caching Gründen; die Anwendung arbeitet dann mit einem Apllikations Benutzer der Datenbank (schon wegen Connection Pooling). Bei Fat Clients legt man dann die gesamte DB Zugriffsschicht auf eine Application Server und das Authentifizierungsproblem wandert von der Datenbank zur Verbindung zum Appserver.
Die stored Porcedures reissen mich nicht gerade vom Hocker, das riecht doch eher nach Verstoß gegen Schichtentrennung und zwingt zur Neuerfindung von Rädern trotz Comtainer managed Persistence von EJBs und Object relational mapping Frameworks.
Ich würde da persönlich immer ein eigenes View Layer für ODBC Zugriffe von Benutzern favorisieren, das leistet wesentlich mehr als Berechtigungskontrolle.

Dieter Bender
Zitat Zitat von Fuerchau Beitrag anzeigen
Naja, schön ist alle Theorie.
Leider wird eben auch bei Client-Server-Anwendungen nicht mit App-Usern gearbeitet, da man die SQL-Funktion USER benötigt (Journale, Trigger, Prüfungen, Berechtigungen).

Daher ist gerade bei Client-Server-Anwendungen dem freien Zugriff per ODBC an der Anwendung vorbei Tür und Tor geöffnet.

Hier helfen selbst die API's nicht mehr, da nun mal der Clientuser ja für die Zugriffe berechtigt sein muss.

Die Anwendung an sich muss da schon generell anders konzipiert sein.
Um mit dem originären User auf der DB arbeiten zu können, muss der SQL-Job sich ja quasi ummelden (QSYSETPH), damit das USER-Register wieder korrekt gefüllt ist.

Allerdings meldet das API nun wieder den umgemeldeten User.

So richtig habe ich bei Client-Anwendungen keine Lösung, ODBC-Zugriffe ausserhalb der Anwendung zu sperren.

Standard-Objekt-/DB-Rechte ziehen da einfach nicht.

Generelle Konzepte mit Stored-Procedures, die Datenzugriffe grundsätzlich verbergen, finde ich da auch eher selten, obwohl mir das die einzige Lösung scheint.