Subject RE: [ib-support] User Management
Author Martijn Tonies
Hi,

>I must admit my stupidity in this area.
>As I understood, the additional process (separate EXE) must be something
>that runs on server and is launched by SYSADM, who connects with his
>password. Then client programs everywere connect throught TCP to this
>program and send/receive info.
>That means that I must create this program in Windows, Unix, Linux,
>etc. wherever my users want to put their server.

Not exactly... The way it's implemented here is:

There's a client application (App A) that is the general users application.
When starting it, the user enters his/hers username/password combination.
Behind the screen, the user will get a valid SQL Role in order to gain
access to the underlying tables.

Then, there's the SYSADMIN application (App B) - when the _sysadmin_ starts
it, he will connect to the database/server as a server administrator. In the
case of IB, the famous sysdba/masterkey combo (change password!). This
password is secret and only known to the sysadmin.

When a new user account is needed, sysadmin fires up App B and registers the
new user. The user is granted the SQL Role so he/she can access the
applications tables... The user is also given a unique username/password
combination from which he/she can change the password (by using, for
example, a special function in App A).

At login-time, App A adds a pre-fix to the username and/or password. App B
will do the same upon creation of the user - hence, my username wouldn't be
MARTIJNT but MYAPP$MARTIJNT - but I don't know that. And hey, perhaps even
sysadmin doesn't know that (depending on the structure of App B). Now, when
a user logs in via App A, he/she will enter MARTIJNT - the app then adds the
prefix, creating a valid log-in for the server and gaining access to the
applications tables/views/procedures.

When the user downloads his favourite InterBase tool (I certainly would use
InterBase Workbench for that :) - he/she would try logging into the system
via MARTIJNT/mypassword - but that fails... Why? Because the users _real_
username isn't MARTIJNT but MYAPP$MARTIJNT (or something)... So, your data
is secured a bit more. And IF the user knows the login name, he/she also
must use the valid SQL role to have true access - else any select/delete etc
will fail...



This is but one of the many ways to accomplish the task :)



Hope this helps,

Martijn Tonies
InterBase Workbench - the developer tool for InterBase and Firebird
http://www.interbaseworkbench.com


[Non-text portions of this message have been removed]