Brief: There are pros and cons to using authorization lists to implement AS/400 security. This article discusses the structure and implementation of authorization lists. With a firm grasp of this information, you should find it easier to make decisions about when authorization lists should be used.

Authorization lists can save time for AS/400 security administrators. An authorization list makes it easy to implement a security scheme that covers multiple objects. For example, individual members of the Accounts Receivable department need different access to the invoice file. In most cases, these authorities will be the same as those required for the customer file. By using an authorization list, the authorizations can be designated once and then applied to multiple objects (both the Accounts Receivable and customer master files).

Once you have a clear understanding of how authorization lists are implemented "under the covers," it is easier to understand when (and when not) to use them. For more information about how to implement authorization lists, refer to "Authorization Lists to the Rescue" (MC, May 1993).

A Conceptual View

Authorization lists are used to secure individual or multiple objects to multiple users. Securing a file, program or other object with an authorization list is equivalent to granting access to each user profile on the authorization list. It is convenient to think of an authorization as two lists, although they are not actually stored this way.

Think of the first list as a register of users and their authority, as depicted in the top half of 1. Each user on the authorization list can have a different authority. You can add a group profile to an authorization list, which is functionally equivalent to putting each member of the group on the authorization list. An authorization will always include a *PUBLIC authority entry.

Think of the first list as a register of users and their authority, as depicted in the top half of Figure 1. Each user on the authorization list can have a different authority. You can add a group profile to an authorization list, which is functionally equivalent to putting each member of the group on the authorization list. An authorization will always include a *PUBLIC authority entry.

The second list specifies objects secured by the authorization list, as depicted in the bottom half of 1. 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.

The second list specifies objects secured by the authorization list, as depicted in the bottom half of Figure 1. 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.

1 does not represent the implementation used by AS/400. Instead, it shows a conceptual view of an authorization list that secures three objects. User profile ELLEN owns the authorization list AUTL1; and NEIL, TRACEY and TROY are granted specific authorities to objects secured by AUTL1.

Figure 1 does not represent the implementation used by AS/400. Instead, it shows a conceptual view of an authorization list that secures three objects. User profile ELLEN owns the authorization list AUTL1; and NEIL, TRACEY and TROY are granted specific authorities to objects secured by AUTL1.

The *PUBLIC entry in the figure indicates that all other users have *EXCLUDE authority. This does not mean that these users do not have authority to the objects-only that it is not granted via the authorization list. The users could have specific authorities to the objects. Refer to "Security Design for Performance" (MC, August 1993) for details concerning other ways to grant authority and how they interact with authorization lists.

An Accurate View

The AS/400 authorization list does not store the list of users as shown in the conceptual view, but I find that it helps to form the conceptual picture of an authorization list as a list of objects and a list of users.

To understand how an authorization list is actually stored, you need some fundamental information about how objects and object authorities are stored on the AS/400. The object header for any AS/400 object contains the *PUBLIC authority and the owner's authority to that object. All other authorities to an object-including authority based on an authorization list-are stored in each user profile that is authorized to the object. The user profiles do not actually contain the names of objects but the virtual addresses of the objects.

All of these rules also apply to the authorization list object. 2 depicts the actual AS/400 implementation of the authorization list shown conceptually in 1.

All of these rules also apply to the authorization list object. Figure 2 depicts the actual AS/400 implementation of the authorization list shown conceptually in Figure 1.

The authorization list does not contain a list of users-each user profile "on the list," other than the owner of the authorization list, has an entry for the authorization list object (i.e., AUTL1). The authorization list does contain a list of objects secured by the authorization list. In addition, the object header of each object on the list has a pointer to the virtual address of the authorization list. For purposes of explanation, let's assume that authority to an object cannot be resolved without reference to an authorization list. In this case, when a user attempts to access an object secured by an authorization list, the system searches the user profile for authority to the authorization list object-TYPE(*AUTL).

In most cases, the security check never accesses the authorization list itself-the exceptions to this rule are if the user owns the authorization list or if it is necessary to use *PUBLIC authority to the authorization list object. If the user profile contains an entry for the authorization list object, the authority specified is also granted for all objects secured by the authorization list. If you secure an object using an authorization list, there will always be a search of user profiles for authority. One reason why excessive use of authorization lists can have a bad effect on performance is the time required to search through the user profile.

If the user is the owner of the authorization list or has no specific authority to it, the system uses the object header of the authorization list to determine whether access should be granted. The *PUBLIC and owner's authorities are stored in the object header of each object. For authorization list AUTL1, the *PUBLIC authority is *EXCLUDE. The user profile ELLEN owns the AUTL1 object. The owner's user profile has an entry for the AUTL1 object but this entry only identifies owned objects-authority for the owner of an object is not stored in the owner's user profile. The owner's authority is stored in the header of the object. Therefore, to determine ELLEN's authority to File 1, the system must access the authorization list object header.

To recap how the search for authorities specified using an authorization list is resolved, refer to Figures 2 and 3.

When to Use Authorization Lists

In some cases, the use of authorization lists can be more advantageous than private authority (authority granted to a specific user profile). Although OS/400 does allow you to concurrently use private authority and an authorization list to secure an object, you should select one or the other to avoid the performance overhead. "Security Design for Performance" (MC, August 1993) discusses performance considerations of these two security methods in detail.

Similarly, you may witness performance overhead even when you've chosen only one of these methods-for example, the use of authorization lists may result in additional authority lookup operations. Yet, this performance overhead does not mean that you should avoid use of authorization lists altogether. Authorization lists are especially useful in the following areas that I will discuss in more detail.

o Securing files that are open for long periods of time. o Securing database files with multiple members. o Using authorization lists to remember private authority. o Securing documents and folders.

Securing Files That are Open for Long Periods of Time

By using authorization lists for files, you can simplify your security management tasks. When a file is open, the system places a lock on the file to prevent it from being deleted by another job; but this lock also prevents any changes to the security of the file.

When you need to change the users authorized to a file that is open for extended periods, you have two choices: 1) wait until the file is not in use, which means that you cannot conveniently make security changes, or 2) secure the file with an authorization list. When the file is secured by an authorization list, you can change the authorization list while the file is open. If you change the security for an open file, it does not alter the access for users who already have the file open.

Securing Database Files with Multiple Members

When you grant a user private access to a database file that has many members, you will observe that the Grant Object Authority (GRTOBJAUT) operation can take a long time. The system translates your request for the physical file into a request for each member and access path of the file. For a file that has 500 members, granting private authority would generate 1001 authority entries (1 file + 500 members + 500 access paths). There will be 1001 private authorizations for each user you authorize to the file, as shown in the top half of 4.

When you grant a user private access to a database file that has many members, you will observe that the Grant Object Authority (GRTOBJAUT) operation can take a long time. The system translates your request for the physical file into a request for each member and access path of the file. For a file that has 500 members, granting private authority would generate 1001 authority entries (1 file + 500 members + 500 access paths). There will be 1001 private authorizations for each user you authorize to the file, as shown in the top half of Figure 4.

If instead you had used an authorization list, each user profile would contain just a single authority entry. (See the second half of 4.) The file, members and access paths have pointers reserved in the object header that point to the authorization list. The authorization list also has an entry for each of the 1001 objects. When you authorize the second user, a single authority entry is created. As a result, adding more user profiles to the authorization list is much faster and creates fewer authority entries.

If instead you had used an authorization list, each user profile would contain just a single authority entry. (See the second half of Figure 4.) The file, members and access paths have pointers reserved in the object header that point to the authorization list. The authorization list also has an entry for each of the 1001 objects. When you authorize the second user, a single authority entry is created. As a result, adding more user profiles to the authorization list is much faster and creates fewer authority entries.

Backing up authority information with the Save System (SAVSYS) or Save Security Data (SAVSECDTA) command saves all the authorization lists and user profile authority entries. Using authorization lists for files with multiple members can dramatically reduce the number of authority entries that need to be saved (in the example of a file with 500 members, the number of entries jumps from 1001 down to 1). Obviously, this reduces the time needed to back up authority.

Using Authorization Lists to Remember Private Authority

When an object is saved, the system saves the object owner's and *PUBLIC authority. If the object has an authorization list, the system also saves the name of the authorization list and the system serial number of the system. The user's private authority to the object is not saved. When the object is deleted, the user's private authority to the object is cleaned up. If an authorization list is used rather than using private authority, deletion of the object does not delete the authorization list where all the users are listed since it may be securing other objects. If the saved version is restored to the same system, the object will be attached to the authorization list.

When an object is restored on a system other than the one where it was saved (i.e., the system serial numbers are different), the system does not automatically attach the authorization list. Since the new system may not reflect the same users, IBM made the secure decision not to attach the object to the authorization list even when the authorization list with the same name exists on the other system. A security officer can use the ALWOBJDIF(*ALL) parameter on the restore commands to restore objects from a different system and attach the authorization list.

Securing Documents and Folders

When the authorization list originated on the S/36, it could secure only documents and folders; and the authorization list was the only way to secure S/36 documents and folders. The AS/400 expanded the means of securing these objects, adding private authority and group profiles to the traditional authorization list. The use of authorization lists expanded as well to include all object types (except authorization lists and user profiles).

Documents and folders differ in some ways from the other AS/400 objects.

o Documents and folders do not transfer ownership to the group profile of the creating user. If a user wants to share the documents he creates, authorization lists offer the best choice.

o Documents created into a folder are secured the same way the folder is secured. If the folder has an authorization list, the users on the authorization list will be authorized to the documents.

o Folders do not act like libraries. A user can access the documents in a folder even when the user is not authorized to the folder. Therefore, the individual documents must be secured. Authorization lists are a convenient way to manage document security.

In most cases, these advantages override any additional performance impact.

A Powerful Tool

Authorization lists are a powerful tool for the management of security. By understanding both the conceptual view and the actual implementation of AS/400 authorization lists, you'll be able to make better decisions about how they fit into your overall security implementation. Bear in mind these rules of thumb: Securing objects with authorization lists can increase the number of authority lookup operations, but the advantages of using authorization lists usually exceeds the slight performance impacts. When you use authorization lists to secure objects, avoid use of private authorities (other than the object owner and *PUBLIC) for best performance.

Wayne O. Evans is an AS/400 security consultant and a frequent speaker on security topics. During his 27 years with IBM Corporation, he was involved with AS/400 security design issues. Direct your security-related questions to Wayne via fax at (507) 252-9615.

Authorization List Internals

Figure 1 Conceptual View of Authorization List

 UNABLE TO REPRODUCE GRAPHIC 
 
 Authorization List Internals
 
 Figure 2 Actual Authorization List Implementation
 
 UNABLE TO REPRODUCE GRAPHIC 
 
 Authorization List Internals
 
 Figure 3 Authority Checks for Authorization Lists
 
 When an object is secured by an authorization list, the system performs authority checks as follows: 1) The system determines if there is any private authority to the object. If there are no private authorities, the system can bypass the search done in step 2. 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 from the object header and no profile search is performed. If the profile contains the address of the object, the authority to the object is retrieved from the user profile. 3) If the user does not have private authority to 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). 4) If no authority is found, steps 1-3 are repeated for the group profile. 5) If no authority is found, the *PUBLIC authority is retrieved from the object header. 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. 
 
 Authorization List Internals
 
 Figure 4 Securing a File with Multiple Members
 
 UNABLE TO REPRODUCE GRAPHICS 

Also Read

IBM i Security Essentials: 4 Components for an Effective Strategy

New IBM i Security Features and a Farewell

Securing IBM i: A Dual Responsibility