Re: Restricting access to Oracle database to only Oracle Forms

From: Kenneth D Atkins <Kenneth.D.Atkins_at_tek.com>
Date: Tue, 28 Feb 1995 18:24:58 GMT
Message-ID: <Kenneth.D.Atkins.8.2F536A7A_at_tek.com>


In article <3icq91$r6a_at_ef2007.efhd.ford.com> wmeahan_at_ef0424.efhd.ford.com (Bill Meahan) writes:
>From: wmeahan_at_ef0424.efhd.ford.com (Bill Meahan)
>Subject: Re: Restricting access to Oracle database to only Oracle Forms
>Date: Tue, 21 Feb 95 13:36:32 GMT
 

>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.

Not all applications have such high security requirements. There may be applications where the security is primarily to prevent users from shooting themselves in the foot! For example an application where input to the database has to be done through the forms, but the user can have access to the data via a query tool.

Also, there are times when we cannot be purists. Some ideas, though repugnant to some, are 'good ideas' given certain situations. I did not say that this was one of those situations, I just pointed out a possibility. It is better to be aware of all of the possibilities, and make your design decision based upon your requirements, taking into account the weaknesses of any solution. OK. Flameback over.

By the way, the password aging problem should not be an issue. The user's oracle password is the primary security for the database. If he cannot get into the instance, he cannot access/mess up the data. This password can be managed just as usual. The primary problem with imbedding the password is that somehow, someone might find out what it is, and if he has access to the same instance, he could use the role to access data that he should not have access to. There may be a way to store the code that accesses the role in a library. This way to change the password, the library would have to be changed and the forms re-generated. This is a pain, but it might be a possibility.



Kenneth D. Atkins
Financial Data Systems Inc.
Kenneth.D.Atkins_at_tek.com
Received on Tue Feb 28 1995 - 19:24:58 CET

Original text of this message