Darren Duncan wrote:
> 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
I should also clarify that this was a decade ago and the context was a desktop
application which maintained an open connection for the person's work day.
Although I think the same technique was also used there for web applications
afterwards, that used the same database, if I don't mis-remember. I believe
this was an Oracle 8 DBMS. -- Darren Duncan
