Do you really understand what authorization lists are and what they do?

Securing a file, program, or other object with an authorization list is the same as granting access to each user profile on the authorization list. To help understand the concept, think of an authorization as two sub-lists:

The first sub-list holds a register of users (or groups) and their authorities. Each user on the authorization list can have a different authority level. You can add a group profile to an authorization list, which in practical terms means the same thing as putting each member of the group on the authorization list.

The second sub-list enumerates the objects secured by the authorization list. Authorization lists can secure any object type except a user profile or another authorization list. Different types of objects can be mixed on the same list. Each user's access from the first list applies to the objects on the second list.

Actually, this is not exactly how the authorization list is implemented in the system, but you should have an idea of how it works now.

In short, each authority level grants different accesses to iSeries objects:

• *ALL is fairly obvious. A user or group profile with *ALL authority for an object can do anything with that object: change the attributes, change ownership, delete it.... It seems redundant to mention that you should be careful when granting *ALL authority. You'll understand why when your main accounting history file (or something worse) mysteriously disappears.

• *CHANGE lets the user or group profile change the object, but this authority means slightly different things for different types of objects. For example, the user can clear, read, or change the records in a database file. But with a program or command object, the user can only use the object. *CHANGE authority does not allow users to delete an object or change any of its security attributes (such as the object's owner).

• Another type of authority that has slightly different effects on different object types is *USE. For a database file, it means users get read-only access. For a program or command object, users can only call (execute) it.

• The fourth specific authority isn't really an authority at all. *EXCLUDE means that users don't have any access to the object. You might call this setting the anti-authority.

In other words, an authorization list contains user (or group) names and their respective authority levels. Putting the bouncer at the club's entrance is like changing an object's security attributes in order to use a certain authorization list: anytime someone tries to access the object, that user's authority over the object is checked (see "Authority Checking Process" below for more details) and the access is granted or not.

Authority Checking Process for Objects Using Authorization Lists

When a user tries to access an object that is secured by an authorization list, the system performs authority checks as follows. (Author's Note: The following list of steps was previously published in "Authorization List Internals" by Wayne O. Evans, Midrange Computing, October 31, 1993.)

• Step 1--The system determines if there is any private authority to the object. If there aren't any, the system jumps to step 3.

• Step 2--The user profile is searched for the virtual address of the object (specific authority). If the user is the owner of the object, access is determined directly from the object header, without any profile search. If the profile contains the address of the object, the authority to the object is retrieved from the user profile.

• Step 3--If the user does not have private authority over the object, the system replaces the virtual address of the object with the virtual address of the authorization list. The user profile is searched for the virtual address of the authorization list. If the profile contains the address of the authorization list, the authority to the object is retrieved from the user profile. (This is actually the user's authority to the authorization list, but this authority will be used for the object access).

• Step 4--If no authority is found, steps 1-3 are repeated for the group profile.

• Step 5--If no authority is found, the *PUBLIC authority is retrieved from the object header.

• Step 6--If the *PUBLIC authority of the object indicates *AUTL, the system uses the *PUBLIC authority from the authorization list header rather than the object header.

Only the Beginning

Watch for the rest of this series to learn more about using authorization lists to keep your system and its data safe.

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