Re: Restricting access to Oracle database to only Oracle Forms

From: Richard Cronau <richard.cronau_at_intelsat.int>
Date: 24 Feb 1995 21:13:18 GMT
Message-ID: <3ili5e$q3p_at_news.intelsat.int>


In article <3i6hehINN57u_at_yellowstone.cis.ohio-state.edu>, patel_at_cis.ohio-state.edu (kant c patel) says:
>
>
>Hi,
>
>I have an Oracle7 server running on a SunSparc 10, and the client software
>runs on PCs & Macs (Oracle Forms & Databrowser). Now, the problem is that I
>would like to restrict access to the database through forms & browser only,
>and not allow the users to directly work on the database using other Oracle
>tools, like, Sqlplus, etc. Is there some way of restricting the tools that
>a user can use to connect to the server (by setting some entries in a table
>at the server, or something like that) ? The reason this is required to be
>done is that we need an additional level of security in the system (in
>addition to the role mechanism), since this is a medical system & lot of
>legal issues are involved.
>
>Thanks in advance,
>
>Kant.
>

I don't think so. What you want to do is to determine what user tool is being used to access the Oracle server. To the best of my knowledge, since all of the user tools go thru SQL*Net, there is no way of preventing access based upon what tool is being used (SQL*Plus, Forms, etc).

To use a forms package, I believe that you would have to set up a table of valid users, and have the application connect via a username/password that is hidden from the user and then validate the user against your own security mechanism.

An alternative is to put the application on the host and require that user execute the application from the host. You would need to run an X emulation package on the client. This way, you would not be going thru SQL*Net. You could then change permissions on the tools that reside on the host such only those that you want the user to use are available. In addition, the listener would not be running so that access to the database is restricted to processes running on the server. This approach could be expanded by use of a three tiered client/server architecture (Database server, application server, client).

I hope this helps.

Regards,

Rick Cronau Received on Fri Feb 24 1995 - 22:13:18 CET

Original text of this message