You could always query the v_$session view and link it to
userenv("USER") and the session information. This will return
the operating system name of the user connecting. You can therefore
make a simple table tying the os username to privileges in your application.
Doing it this way places the authenication upon the OS ( NT, UNIX etc).
Dan
Ed Stevens <Ed.Stevens_at_nmm.nissan-usa.com> wrote in message
news:7pjsvp$u3t$1_at_nnrp1.deja.com...
> I'm sure this issue has been beat to death before, so please bear with
> me. I'm seeking "best practice" ideas for logon security for Oracle
> databases in an NT environment.
>
> Currently, we are having applications use a single, common userid (say,
> "AppUser") to log on to the databases. Obviously, we do not wish for
> that userid/pswd to become known because with it a user could use
> Excel, Access or any other tool to connect to the database with full
> update authority and without the constraints imposed by the
> applications. We have separate development projects going on in
> Powerbuilder, Visual Basic, and Cobol. The problem is how to deliver
> the userid and (more importantly) the password to the applications from
> a central "repository" so that they don't have to hard-code them into
> the app.
>
> So, my question is "how do your home-grown apps know what user-id/pswd
> to use and how do you secure this information from the general user
> community? Secondly, do you make any attempt to hide the password from
> the application developers?"
>
> Could the use of roles be part of the solution? If so, how?
>
> TIA.
>
> Ed Stevens
>
>
> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.
Received on Sat Aug 21 1999 - 09:55:35 CDT
