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)

and

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.

Rafael Victória-Pereira has more than 20 years of IBM i experience as a programmer, analyst, and manager. Over that period, he has been an active voice in the IBM i community, encouraging and helping programmers transition to ILE and free-format RPG. Rafael has written more than 100 technical articles about topics ranging from interfaces (the topic for his first book, Flexible Input, Dazzling Output with IBM i) to modern RPG and SQL in his popular RPG Academy and SQL 101 series on mcpressonline.com and in his books Evolve Your RPG Coding and SQL for IBM i: A Database Modernization Guide. Rafael writes in an easy-to-read, practical style that is highly popular with his audience of IBM technology professionals.

Rafael is the Deputy IT Director - Infrastructures and Services at the Luis Simões Group in Portugal. His areas of expertise include programming in the IBM i native languages (RPG, CL, and DB2 SQL) and in "modern" programming languages, such as Java, C#, and Python, as well as project management and consultancy.

---

MC Press books written by Rafael Victória-Pereira available now on the MC Press Bookstore.

		Evolve Your RPG Coding: Move from OPM to ILE...and Beyond Transition to modern RPG programming with this step-by-step guide through ILE and free-format RPG, SQL, and modernization techniques. List Price $79.95 Now On Sale
		Flexible Input, Dazzling Output with IBM i Uncover easier, more flexible ways to get data into your system, plus some methods for exporting and presenting the vital business data it contains. List Price $79.95 Now On Sale
		SQL for IBM i: A Database Modernization Guide Learn how to use SQL’s capabilities to modernize and enhance your IBM i database. List Price $79.95 Now On Sale

Also Read

Authentication and Authorization: Why? Part 3: A Word About Privileged Account Management

Authentication and Authorization: Why? Part 2: Query-Response Language & Policies

Authentication and Authorization: Why? Part 1: Access