A practice I like that I've seen done for a federal-government scale database
program is to have each person using the application to login to the database
using their own temporary database user. How it works is that the database has
a users table similar to as if the application was managing users itself, and
when the person logs in they are using credentials defined in that table. What
actually happens for login is that there is a special database user which only
has privileges to execute a single stored procedure, and the application's login
screen talks to the database with that special user and invokes the procedure,
giving the person-provided user and pass as procedure arguments. The stored
procedure checks the database table, and if the credentials are accepted, the
procedure then generates a new database user and password and gives these back
to the application, which then turns around and logs in as the temporary user in
order to do all the normal work of the person. This generated user only has the
privileges that the person needs. This approach seems to have security benefits
of some kinds. -- Darren Duncan
