At 11/29/2001 05:36 PM (Thursday), Dion wrote:

>Has anybody been able to securely allow a DBA to administer user rights
>seperately from IB(or any other DB for that matter). What I mean is
>storing user rights in a seperate table. This means that the logon names
>are not save to IB system tables. The problem I found is hiding the
>initial app logon user name and password. Where do you hide the user name
>and password the app needs to initially logon in order to get access to
>the other user table in order to authenticate user access, in a secure fashion?
>
>Will burying it in the app have to do?

Yes, if that's the way you need to do solve the overall problem. I don't
consider it an ideal solution.

In my case I have left all the usernames and passwords in the security
database. I then ensure every username listed has read access to the
security database and to the tables which store various rights which the
application maintains. The application can then use the user's own username
and password to login to the server (the normal way) and get access to the
application's rights tables. The application then knows what the user can
do. This way no sensitive data is stored in the application.

Another part of the application can be used by administrators to add,
delete, update username and passwords. It also does similar maintenance on
the rights tables maintained by the application.

Pretty much everything is remotely managed, while keeping the server locked
away. The key to all this is being able to access the security database
remotely. I have a UDF in the database which returns the location of the
security database from the server's perspective so the admin application
can open it as a regular database. I also have duplicated the password
encryption algorithm (in Delphi) so the application can match the encrypted
form against the one stored in the security database. After these two items
are taken care of the rest is just normal application logic.

Hope this helps!