RE: Athuorization lists

midrange-l-request@xxxxxxxxxxxx wrote:

>   1. Athuorization lists (Douglas W. Palme)
>
>Is there a clean way to keep up to date with authorization lists? We have 
>revamped some of our menus and would like to control who has access (*USE, 
>*ALL, etc. ) to the program objects and even some menus.
>
>Some of the programs, workfiles, etc. would require authority to clear them, 
>etc. and I was wondering how some of the rest of you handle these types of 
>issues.
>
>I know I can give a user authority to a secific object but is that the best 
>way to handle it or use authorization lists?


Douglas:

Here's a small app structure:

MENU1 is a menu program with --
 1. Call PGMA
 2. Call PGMB
 3. Call PGMC
 4. Go MENU2

MENU2 is a menu program with --
 1. Call PGMD
 2. Call PGME

PGMA does CLRPFM FILEA. PGMB does adds/changes/deletes to FILEA. PGMC does 
inquiries over FILEA and refers to FILEB for secondary stuff.

PGMD is a FILEB maintenance program. PGME is FILEB inquiry.

There are two entry points to the app -- MENU1 & MENU2. There's no need for any 
user to CALL PGMC for example because MENU1 option 1 does exactly that. And 
there is no need to do a RUNQRY over FILEA because MENU1 option 3 can handle 
that.

That is, there are only two objects that users need authority to -- MENU1 & 
MENU2.

Why?

Because there is a profile called PRF1 that owns MENU1 & MENU2 and those 
programs are created with USRPRF(*OWNER). And all of the other objects in the 
app are secured with the APPOBJ *AUTL and the only user on that list is PRF1.

Now, MENU1 & MENU2 are secured by a second *AUTL -- APPENTRY. When you want a 
user to get into the app, you grant him/her *USE rights to APPENTRY. That gives 
them rights to the application entry points but nothing else.

PGMA, PGMB, etc., are all created as USRPRF(*USER) USEADPAUT(*YES). When MENU1 
calls PGMA, PGMA can run even though the user has no authority to it. The 
authority doesn't come from the user; it comes because the MENU1 program itself 
has authority via USRPRF(*OWNER) and PGMA was told that it was allowed to use 
adopted authority. And when PGMA tries to clear FILEA, the authority again 
doesn't come from the user; it comes from the adopted authority that was passed 
to PGMA from MENU1.

In the meantime, if the user wants to get clever and type CLRPFM FILEA on a 
command-line, it won't work -- no authority to FILEA. Or if user tries to do 
CALL PGMA from a command-line, it won't work either -- no authority to PGMA. 
That is, no authority unless it's propagated down from an entry point. When 
authority to CLRPFM FILEA is needed, it's there automatically. There is no 
authority granted a user except the single *USE to an *AUTL.

Data cannot be accessed except through the application. Application programs 
cannot be accessed except through the entry points that you define. And the 
only private authorities are the ones that are granted to the entry *AUTL.

That's a basic description of how *AUTLs might be used for application security.

It's also perfectly possible to have a group profile that is added to the entry 
*AUTL. Then a user could be made a member of that group and pick up needed 
authority rather than adding each user to the *AUTL. And note that even the 
group profile has no authority outside the entry point.

We use a refinement of all of that that has a separate owner profile, separate 
from what we call the 'administrator' profile that owns the entry points. The 
owner profile owns all application objects _except_ the defined entry points. 
There are very few spots where some special authority is needed; the separate 
owner profile has special authorities needed by the app and that authority is 
made available by having a very few programs that are _not_ entry points and 
that are also created as USRPRF(*OWNER). Since only the administrator is 
authorized to those programs, the programs can only be run under control of the 
app.

We also have separate *AUTLs for application program objects and data objects 
rather than a single *AUTL for all non-entry objects, but the app administrator 
is still the only profile on each. When necessary, we also have a 'reporting' 
*AUTL that allows certain users to access various reporting-only functions. For 
reporting, there are also entry-points and those are the objects controlled by 
that *AUTL.

Refinements can added in many ways.

But the basics come down to controlling the entry points and locking everything 
else down.

That's Chapter 1 in the Intro to *AUTLs topic.

Chapter 2 would cover the special case where only a select few should be 
allowed access to MENU2 where the sensitive stuff is, but that can be 
extrapolated from what you've learned in Chapter 1. As a wise man once said 
"Positing infinity, the rest is easy."

Tom Liotta