Re: Security Products

You might also want to look at SECURE*DB from DBCORP. It is a client/server security product that allows you to syncronize end-user passwords on multiple databases. It provides a API call to check the password and can be set up to facilitiate paaword protected roles or a 'shadow' user id that seperates the users application access from their ADHOC access.

Look at http://www.dbcorp.ab.ca/products for info and trial downloads.

On 20 Feb 1997 17:15:12 GMT, sturner_at_athena.mit.edu (Stephen Turner) wrote:

>Don't know of any 3rd-party products, but we have the same situation
>and it might be useful to share what we found out about this.
>
>2 questions about your case - is anyone connecting via SQL*NET and
>what is your OS_AUTHENT_PREFIX set to?
>
>If no-one is or will be using SQL*NET to connect, you can safely
>use OS authentication and have the scripts use "/" to connect.
>Obviously you are then relying on the OS for security, but I'll
>assume that's OK.
>
>If you are going to use SQL*NET, AND your OS_AUTHENT_PREFIX is set
>to OPS$, you can identify your Oracle users by password and still
>use OS authentication. This means that a SQL*Net user would be forced
>to enter their Oracle password on connection but any user logged
>on to the UNix machine or any job running could connect using just a
>"/".
>
>Howerver, the OPS$ prefix is apparently available only for 'backward
>compatibility' with older Oracle versions so it may be risky to
>use this approach.
>
>Lastly, if you will be using SQL*Net and your OS_AUTHENT_PREFIX is set
>to something other than OPS$ (NULL for example) then there's no way
>around having to have everyone use passwords and maintain security
>with SQL*Net.
>
>So, our solution was to do what you suggested, and store passwords
>in a secure file which we decided gave acceptable security - there's
>never a perfect solution, just levels of security...
>
>Steve Turner
Received on Sun Feb 23 1997 - 00:00:00 CST