Support MC Press - Visit Our Sponsors

 

Forums Sponsor

Popular Forums

POPULAR FORUMS Amen on the GUI (538 views) Upload question (449 views) COBOL on the AS/400 (416 views) Parsing XML using XSL in RPGLE (404 views) Namespace for RPG procedures (307 views) Comment on: TechTip: Automate Data Transfers Using FTP (286 views) VARLEN in DDS vs. VARCHAR in DDL (280 views) Trying to add images to an overlay (259 views) "When you're wrong, admit it quickly and emphatically" (251 views) Upload TXT to Source PF (250 views)

Forums

 

Search Sponsor

  

Popular Searches

POPULAR SEARCHES 1. sql2xls 2. Tom Snyder 3. php 4. pdf 5. subfile 6. XML 7. java 8. SQL2XML 9. FTP 10. gregory

Search

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.