If you're not properly using authorization lists, you could be in big trouble.
In Part I of this series, you learned what authorization lists are and what they do. Now, let's consolidate all that information with an example.
Company X has a Human Resources application running on its system. Several users from different departments need to access the application for various purposes:
John and Mary, from the HR department, must be able to use the application in their daily work, managing the HR; Steve, from Accounting, only needs to read the HR records to process the salaries of the staff; finally, Bruce, the internal auditor, wants to run some queries over the HR application's database to ensure consistency and compliance with the internal procedures.
Tommy, the new programmer, is a nosy kid who wants to know how much money everyone else makes...and he shouldn't be allowed to!
Assume that the application has only one library, called HR_APP, where all its objects (programs and files) reside. With this information, we're ready to create our first authorization list, using this command:
CRTAUTL AUTL(P_HR_AUTL) TEXT('Production HR App Authorization List') AUT(*EXCLUDE)
Now let's add the users, according to their access requirements.
John and Mary (from the HR department) need sufficient access to change and delete records. We might be tempted to give them *ALL authority, but keep in mind that they might accidentally delete a program or file. *CHANGE should be enough for their needs:
ADDAUTLE AUTL(P_HR_AUTL) USER(JOHN MARY) AUT(*CHANGE)
Steve and Bruce, from Accounting and Internal Audit, respectively, need the same type of access: read-only. This is implemented as *USE, because (as mentioned before) this authority corresponds to different behaviors, depending on the object type: they should be able to execute programs but unable to change data. Here's how to grant them the necessary authority:
ADDAUTLE AUTL(P_HR_AUTL) USER(STEVE BRUCE) AUT(*USE)
Finally, we need to do something about Tommy! There are at least two ways to solve the problem: either deny him access explicitly (by adding him to the authorization list with *EXCLUDE) or implicitly (by setting the *PUBLIC authority of the authorization list to *EXCLUDE). I recommend you use the *PUBLIC authority, because you never know how many "Tommies" (and I'm not talking about programmers or IT staff only!) you might have in your organization.
Note that the last parameter (AUT) of the authorization list creation command was set to *EXCLUDE in the beginning of this example. This will be the authority given to all the users and groups not mentioned in the authorization list. Even though by default the AUT parameter contains *CHANGE, always setting it to *EXCLUDE is considered good practice. Of course, you can always change the *PUBLIC authority after creating the authorization list.
Now, we should change the security attributes of all the objects in library HR_APP in order to have them under our authorization list control:
GRTOBJAUT OBJ(HR_APP/*ALL) OBJTYPE(*ALL) AUTL(P_HR_AUTL)
Finally, to ensure that the objects don't have any private authorities (defined directly on the object) and that the *PUBLIC authority won't compromise your security scheme, make sure that all the objects are under full authorization list control:
RVKOBJAUT OBJ(HR_APP/*ALL) OBJTYPE(*ALL) USER(*ALL) AUT(*ALL)
GRTOBJAUT OBJ(HR_APP/*ALL) OBJTYPE(*ALL) USER(*PUBLIC) AUT(*AUTL)
Here, the first command revokes (removes) any private authorities that might exist on HR_APP's objects, and the second changes the *PUBLIC authority of all the objects in HR_APP library to use the authorization list's *PUBLIC authority.
You should submit these commands to batch and schedule them to a date/time when the application is not being used (in other words, the library and its objects are not locked by interactive or batch jobs).
To complete our little example, note that the Work with Authorization Lists (WRKAUTL) command enables you to easily manage the authorization lists (see Figure 1).
Figure 1: With WRKAUTL, you can easily manage your authorization lists.
You can find more information about the WRKAUTL command here.
You could improve this authorization list by creating a group for the HR users and replacing their individual authorities on the authorization list by the group.
This is just an example, a starting point. You should analyze and plan carefully each authorization list that you create on your system.
In Part 3, I'll explain the advantages of using authorization lists.
MC Press Online