Hallo,

man muss sich erst mal entscheiden ob der Client (sprich der Rechner) vertrauenswürdig ist, oder nicht; wenn selbiger bei der Anmeldung abprüft und dann Berechtigungen steuern kann, dann vertraut man ihm im allgemeinen, tut man das nicht, dann muss der Anwender vor Aufruf einer gesicherten Anwendung einen Bewis erbringen wer er ist (Benutzer Kennwort oder etwas adäquates).
Jetzt kommt die Anmeldung am Server (AppServer oder Datenbank Server, oder what ever). Selbige erfolgt tunlichst nicht mit einer persönlichen Berechtigung des Anwenders, sonst darf er das alles ja auch unkontrolliert mit einem beliebigen Frontend über ODBC, JDBC, oder das entsprechende Protokoll der Anwendung. Also braucht man jetzt einen AnwendungsBenutzer, der sich connected, dessen Kennwort muss geschützt abgelegt sein, also lokal verschlüsselt (sonst kanns der Anwender lesen), oder hart im Programm, oder remote auf einem entsprechenden Authentikations Server.
Die Berechtigungs Differenzierung innerhalb der entsprechenden Server Domain (in unserem Fall Datenbank), kann jetzt in der Applikation, oder der Datenbank erfolgen, wenn die Anwendung jetzt auf einem Server läuft (WebServer oder AppServer), dann entscheidet man sich meist für Applikations Level (aus Pooling und Cashing Gründen), handelt es sich um einen Fat Client, dann kann man das auch der Datenbank überlassen, wenn die das kann. Persönliche Benutzer scheiden hier meist wegen des zu treibenden Aufwands aus, meist hat man ein paar Rollen, für die jeweils ein Benutzer zur Verfügung steht. Für den Wechsel zur passenden Rolle muss der Anwender einen Beweis haben, dass er diese Rolle spielen darf und im diskutierten Beispiel braucht er noch einen Beweis, dass es die Applikation ist, die den Wechsel zu der Rolle vornimmt, für die Anmeldung kann man durchaus die API Lösung mit dem Profile Switch nehmen. Bei ODBC dürfte das etwas schwieriger als bei JDBC sein (soweit der Benutzer an die DSN auch mit Excel drankommt), dann muss man halt die Kennwörter in der entsprechenden Datei nochmal mit einem Schlüssel verschschlüsseln, den nur die Applikation und nicht der Benutzer kennt (der kann wieder verschlüsselt lokal abgelegt sein, oder hard codiert in der Anwendung, oder remote auf einem Authentikations Server).

Noch ein paar Anmerkungen zur "schönen alten Welt": ich habe bisher so gut wie keine Umgebung gesehen, in der adopted Authority korrekt und sicher implementiert war. Spätestens, wenn man eine Command Line mit der Berechtigung eines solchen Einstiegsprogrammes kombiniert, dann frisst einem der Rechner aus der Hand.

Dieter Bender,

der seine Tätigkeiten im Bereich Security eingestellt hat, weil er keine Lust mehr hatte seinen Kunden Dinge zu erzählen, die sie nicht hören wollten und Sachen zu zeigen, die sie nicht sehen wollten.
Zitat Zitat von Fuerchau
Selbst wenn die Prozedur bekannt ist sollten die dazu benötigten Parameter eben nicht bekannt sein.
Die Prozedur muss die Sicherheit leisten dass Sie eben nicht einfach so aufgerufen werden kann.
Andererseits darf es auch kein Benutzerprofil geben, dass eine 5250-lose Anmeldung erlaubt (also ODBC).

So auf die Schnelle fällt mir hierzu nichts ein, es muss aber gehen. Schließlich haben auch andere Datenbanken (SQL-Server, Oracle o.ä.) die selben Probleme wenn es um freie ODBC-Zugriffe geht.
Andere DB's noch um so mehr als dass dort ein Umschiessen des Users nicht möglich ist.

Die Anwendung meldet sich mit eine APP-User an. Dieses Kennwort hierzu muss verschlüsselt abgelegt oder programmiert werden so dass eine normale Anmeldung ausserhalb der Anwendung mit diesem Userprofil unmöglich gemacht wird.
Dann klappt auch das Umschiessen des Users mit einem temporären internen Kennwort dass ausschließlich der Anwendung bekannt ist.
Die dazu nötigen Profile sind selbst wiederum nicht anmeldefähig.
Man kann sogar mal probieren ob QSYGETPH/QSYSETPH mit disabled Profilen möglich ist.

Vielleicht hat ja mal jemand Zeit dies zu probieren.