Thanks for your time and effort, Doug. A few questions though.

In order to do inserts, deletes etc, you need to have more than read rights.
If the app is logged on under the users name(who has read rights to the
security table) what rights does this user have on the other tables in the
db?

At what point do you assign the user the necessary rights to do inserts,
deletes etc? If you do this on the fly, what happens if the system crashes
before you can restore the read only rights in the system security table?

What I want to do is not allow the user to log onto the db outside of the
app using this logon name and rights, and using a tool like ibconsole to
stuff up the works.

Could you expand on these a little?

>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

Thanks,
Dion.

----- Original Message -----
From: "Doug Chamberlin" <DChamberlin@...>
To: <ib-support@yahoogroups.com>
Sent: Friday, November 30, 2001 1:46 PM
Subject: Re: [ib-support] IB Logon


> 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!
>
>
>
> To unsubscribe from this group, send an email to:
> ib-support-unsubscribe@egroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>