Authority Search Algorithm

Now that we have defined all the types of authorities and the various ways a user can gain these authorities, we need to look at the search algorithm to see how authority is actually granted. As we will see, a very specific search order is always used. The reason for this specific order is to allow users to be granted more or less authority for an object than the public, group profile, or authorization list authority.

The authority-search algorithm is implemented in SLIC when the user first accesses the object. This was part of the resolve-pointer operation we looked at in Chapter 5. The search algorithm stops when the requested authority to the object is found. If no authority is found, the access is denied.

Figure 7.2 shows the progression of the search algorithm as it looks for the requested authority. To illustrate how this works, let us assume we are requesting CHANGE authority to some object in the system. The search order is as follows:

1.  Search the individual user profile for

•  All-object special authority, or

•  Object authority (owner and private authority), or

•  Authorization list authority if object is on an authorization list (private authority)

Access to the object is allowed if the individual user has all-object special authority or at least CHANGE authority for the object in the users profile (owner/private object authority) or in an authorization list. If the authority is found to be less than CHANGE (i.e., USE or EXCLUDE), the algorithm jumps to check adopted authority. If no authority is found, the group profile is checked.

2.  Search the group profiles for

•  All-object special authority, or

•  Primary group authority, or

•  Object authority for other groups (private authority), or

•  Authorization list authority if object is on an authorization list (private authority)

Access to the object is allowed if the group has all-object special authority or at least CHANGE authority for the object in the primary group, other groups, or an authorization list. If the authority is found to be less than CHANGE (i.e., USE or EXCLUDE), the algorithm jumps to check adopted authority. If no authority is found, the public authority is checked.

3.  Search public authority for

•  Object authority (public authority), or

•  Authorization list authority if object is on an authorization list (public authority)

Access to the object is allowed if the public has at least CHANGE authority in either the object or the authorization list authority. If the authority is found to be less than CHANGE (i.e., USE or EXCLUDE), the algorithm jumps to check adopted authority.

4.  Search adopted profile for authority
Access to the object is allowed if the adopted user profile has at least CHANGE authority. If not, access is denied.

Figure 7.2  Authority Search Algorithm

By searching the individual user profile first, and always taking the first authority that gives the desired access authority, the user can be granted more or less authority for an object than the public or group profile allows. If in our example above we put the EXCLUDE authority in the individual user profile and CHANGE in the adopted profile, direct access to the object by the user is blocked. However, the user still can perform the change operations on the object with the adopted authority (s)he acquired while running an adopted program. This is the most common way to restrict access to a system object.

To speed up the search algorithm, two fast paths are used during the authority check. Both of these fast paths rely on information stored with the object, which can be checked quickly without the need to do the series of tests required by the full algorithm. If the conditions in the fast paths are met, the requested operation is allowed. If the conditions in the fast paths are not met, the normal authority search algorithm is performed.

The Need for More Security in a Networked World

In Chapter 11, we take a closer look at the move to network computing and the changes that are occurring in the AS/400. In this chapter, however, we take a brief look at the security implications that arise when any nonsecure system is attached to an AS/400, be that a PC on a LAN or another system on the Internet. Only then can we better understand how to use the security in the AS/400 to protect our business information assets. Let’s start by looking at client/server applications and the attachment of PCs to an AS/400.

Attaching PCs to an AS/400

Many businesses already have implemented their own client/server applications or purchased such applications from ISVs. For these applications, PCs are attached to an AS/400 through a LAN connection, and the application is split between the PC and the AS/400. Many businesses believe that their AS/400 data is safe from unauthorized accesses in these client/server environments. Unfortunately, many times it is not. The security of the data all depends upon how the application was written and how the system has been secured.

The PC side of a client/server application needs some way to access the AS/400 database. This access is usually provided via some file-level access tool on the PC. One fairly common approach is to code the PC application using Open Database Connectivity (ODBC) APIs. With an ODBC application on the PC, there is no need to have an application running on the AS/400. Therefore, it is not possible to use facilities such as program adoption of authority to protect the database files. Instead, the PC program must be directly authorized to the database files through public, group, or private authority. The problem occurs when the end user on the PC should not have full authority to these files, and the PC client application is relied upon to somehow restrict this authority. In general, such authority restriction does not work, and a security exposure exists.

PC clients, as well as many other systems that can be connected to an AS/400, are inherently nonsecure. By that I mean you cannot depend on any code designed to restrict access to the AS/400 if that code is running in a nonsecure system. For example, any software in a PC, including Windows 95 and Windows NT Workstation operating-system software, can easily be modified by a knowledgeable PC user to operate in a way that was not originally intended. This means you cannot rely on any application code running in a PC to provide any level of security for the data in the AS/400, or for the data in the PC, for that matter.