Re: Restricting access to Oracle database to only Oracle Forms

From: Bill Meahan <wmeahan_at_ef0424.efhd.ford.com>
Date: Tue, 21 Feb 95 13:36:32 GMT
Message-ID: <3icq91$r6a_at_ef2007.efhd.ford.com>


Kenneth.D.Atkins_at_tek.com (Kenneth D Atkins) wrote:
>You could setup a database role with a password, give it the appropriate
>access to your application and hard code the password into your
>application's startup form. There is a discussion and example of this in
>appendix J of the Oracle*Forms reference manual.
>

And how do you provide password aging and force change of passwords every N days as required by many security policies and procedures, both corporate and governmental?

Embedding passwords in clients (whether shown in some "Appendix J" or not) is not a very bright idea.

Views and procedures, as referenced in another reply, help but are still limited to by the paradigm that secuity goes (only) with the user. For many applications (e.g. an order-entry clerk on the cable shopping channel) that works just fine since an individual user probably uses just one application. In the situation where someone uses _many_ applications as aids to their job (e.g. a manufacturing engineer who must get at and/or maintain production information, product release information, component cost information etc.) where access is sometimes by complex front-end application and sometimes by ad-hoc tools, the paradigm breaks down.

More often, security needs to be a function of the set (user_id, application, instance) so that, for instance, an application developer can muck about with his/her application on a test instance but can't do diddly-squat on a production instance or so Jane User can, as is appropriate to her job, use THE_Application to maintain data in certain tables (where audit trails and other related data are handled by the application logic and are not readily handled by triggers) but cannot use some general-purpose access tool like Q+E Database Editor to change the same tables since the audit trails and other related data won't be maintained.

It's NOT a trivial problem :-)

--
Bill Meahan,  Senior Developer  |        wmeahan_at_ef0424.efhd.ford.com
Electrical & Fuel Handling Division, Ford Motor Company
Opions expressed herein are those of the author and in no way represent
any official statement or opinion of Ford Motor Company
Received on Tue Feb 21 1995 - 14:36:32 CET

Original text of this message