AS/400 security can be a little intimidating. There are so many features and options that it seems impossible to determine how applications will interact with objects. But waitapplications are objects! How will their security attributes affect their access to other objects? What about adopted authority? What happens with TCP/IP? Too many questions. Too much to understand. What about blowing it all off and having a beer?
The good news is this: While there is a lot to know about the AS/400s security features, you can understand how to configure those features. This article will help you establish a working understanding of object-level security and what paths applications will take when accessing objects. Simply put, object-level security allows you to control not only access to objects but also the type of access users have.
The AS/400 allows four basic types of access to objects. *ALL means you can access anything; *CHANGE lets you change objects; *USE lets you use the object; and finally, *EXCLUDE means you cant access anything. These can all be applied at the user, group, or authorization-list level.
Why are there so many security features? Good question. Im sure I dont know, but I have a guess. The U.S. Department of Defense is (and almost always has been) the single largest purchaser of computer equipment in the world. The U.S. Department of Defense likes security features. It may interest you to know that the AS/400 is the first system with an integrated database to meet the departments criteria for its C2 level of security. In order to obtain a C2 rating, a system has to meet strict criteria in the areas of access control, user accountability, security auditing, and resource isolation. If you think about it, discretionary resource control and isolation basically mandate object-level security.
Securing the Object
Every object in the system has its own list of authority attributes. This list is, in essence, a description of who can do what with the object. The first item in the list is the objects owner.
Who owns the object? When the object is first created, the user profile of its creator is the objects owner. By default, the owner has *ALL authority. That is, the owner can use, change, or delete the object. If the owners user profile is deleted, ownership falls to QDFTOWN, the system default. Using the Change Object Owner (CHGOBJOWN) command, you can transfer ownership to another users profile or to a group profile. For
example, when I develop an application for my companys enterprise resource planning (ERP) system, I change its ownership to the group profile associated with the systems users. This avoids access control problems. (Security officers, of course, have *ALL authority over all objects.)
Using the Work with Objects (WRKOBJ) command, or the specific object authority commands, you can grant (with the Grant Object Authority [GRTOBJAUT] command), revoke (with the Revoke Object Authority [RVKOBJAUT] command), or modify (with the Edit Object Authority [EDTOBJAUT] command) an objects specific authorities. By specific authorities, I mean those authorities granted to (or taken away from) a user or group profile to give the profile a specific type of access.
As I stated, there are actually four types of specific authority. The first, *ALL, is fairly obvious. A user or group profile with *ALL authority for an object can do anything with the object. It seems redundant to point out that you should be careful when granting *ALL authority. Youll understand why when your transaction history file 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 you to delete an object or change any of its security attributes (such as ownership).
Another type of authority that has slightly different effects on different object types is *USE. For a database file, it means you can read records. No deleting, no updating, no writingjust reading. For a program or command object, you can call (execute) it, and thats it.
The fourth specific authority isnt really an authority at all. *EXCLUDE means that you cant do anything at all with the object. You might call this setting the antiauthority.
If you dont have specific authority to an objectthat is, if youre not a security officer or the objects owneryour authority reverts to whatever *PUBLIC authority is set. The *PUBLIC authority attribute controls the general publics access to the object. By general public, I mean the systems users who arent specified in an objects authority attribute.
Many shops set *PUBLIC to *EXCLUDE as a matter of policy. I can best illustrate the reason with an example. If a user has *USE authority to an object and that authority is revoked, the user may still have *USE authority because the public has it. Using *EXCLUDE prevents accidentally granting people access they shouldnt have. There is a downside, however: The tighter your systems security is, the more time youll spend administering security on your system. Only you can decide if your time investment is appropriate.
Authority Administration Made Easy
Of course, granting, editing, and revoking authorities by user profile for a system full of objects could take a lot of time, and you have deadlines. What are you supposed to do? Fear not, gentle reader. IBM, the fount of all goodness, has anticipated this need and provided a tool called an authorization list. As shown in Figure 1, an authorization list is simply a list of user profile names with specific authorities for each one. And, you guessed it, an authorization list is also an object.
Naturally, an object can have both specific authorities and an authorization list. Users can even be in both places. This may be redundant, but it is not harmful.
The authorization list commands let you create (Create Authorization List [CRTAUTL]), delete (Delete Authorization List [DLTAUTL]), and edit (Edit Authorization List [EDTAUTL]) authorization lists. The authorization list can then be applied to objects or groups of objects with GRTOBJAUT or WRKOBJ. There is a caveat, however: In a
development environment, using authorization lists can lead to trouble when moving or restoring objects to a system that doesnt have the authorization list.
You can also grant special authorities to specific users. While I wont go into great detail here, users can be granted special types of authority to objects. For example, you can grant a user *SAVSYS special authority. This lets the user back up and restore objects even when she has no authority to the object. See the references at the end of this article for publications that explain the special authorities in detail. My personal favorite is The AS/400 Owners Manual by Mike Dawson.
Adopted AuthorityYou Are What You Execute
IBM also provides a special kind of authority attribute for executable programs called adopted authority. When compiling, you can set the programs user profile attribute to either *USER or *OWNER. *USER means that the program uses the users authority to access objects. *OWNER means that the program uses its owners authority to access objects.
How does this help? Once again, Ill illustrate with an example. Suppose you have a transaction history file that you want users to be able to add transactions to but you dont want them to be able to, clear the file. If you give the users *CHANGE object authority, they can clear the file. If you give them *USE, they cant clear the file, but neither can they add records. What do you do?
Well, one thing you can do is write a program to maintain the transaction file and set the programs user profile attribute to *OWNER. Then you transfer ownership of the program object to a user who does have *CHANGE authority for the transaction file. When the program is executed (no matter by whom), it has *CHANGE access to the transaction file, even if the user running the program has *EXCLUDE (non)authority for the transaction file. This is only one situation in which adopted authority comes in handy. There are many other possible scenarios, too numerous to mention here.
As Figure 2 illustrates, you can use the Change Program (CHGPGM) command to change whether a program uses adopted authority and whether it uses the user profile or its owners profile to access objects.
Adopted authority has some risks, however. Programs that use adopted authority (which is the default, by the way) can inherit it from programs higher in the call stack. Go back to my example of the transaction file. Suppose that the maintenance program also serves as an inquiry program by using a program status subroutine to handle authority errors. Users who have *CHANGE authority can use the program to add transactions to the file, and users who have *USE authority can only view the existing entries. The inquiry program is set to use adopted authority. (Remember, this is the default.) A user calls the inquiry program from within another program that has its user profile set to *OWNER, and the owner of the program has *ALL access to the transaction file. Now the user can change the file, when you wanted only to grant him access to use the file. Obviously, this is an extreme example that I have concocted expressly for the purpose of illustrating my point. You can provide adopted authority without realizing it, so be careful!
You can prevent adopted authority by setting the USE adopted authority parameter to *NO (see Figure 2 again). Then, a program will not inherit authority from a program higher in the call stack. In my little example, the user now would not be able to change the transaction file.
Tying It All Together
OK. Ill get back to the main point. How does object-level security affect your application? Leaving out adopted authority, your application will access objects (or attempt to) with your users authority, your users group authority, and public authority.
Take a look at another example. Suppose a files authority list excludes *PUBLIC, grants *USE to the group profile named GRPPRF, and grants *CHANGE authority to user CHGUSR. You have an inquiry program that opens the file for read (input only) and a maintenance program that opens the file for update (full function). CHGUSR executes the maintenance program that opens the file for update. Theres no problemCHGUSR has *CHANGE access. CHGUSR can also execute the inquiry program without any difficulty.
Along comes READUSR, who belongs to the group profile GRPPRF, which has *USE authority for the file. READUSR, being a very bad typist, calls the maintenance program. Ka-boom! Theres a program error. Neither READUSR nor GRPPRF has *CHANGE access, which the program needs. READUSR realizes his error and calls the inquiry program. Again, this isnt a problem. GRPPRF has *USE authority over the file, and READUSR is a member of GRPPRF.
Then, along comes NONUSR, who is not mentioned in the files authority attributes. NONUSR is, therefore, a member of *PUBLIC with respect to the file. NONUSR tries to execute the inquiry program. Ka-boom! Theres a program error. NONUSR has no rights. Go back to adopted authority. Change the inquiry programs USRPRF attribute to *OWNER and change its ownership to READUSR. NONUSR can now execute the inquiry program.
Things ExternalThose Darn PCs
Now things get a little more complicated. A user running Client Access can use a tool based on ODBC or ActiveX Data Object (ADO) to access objects on the AS/400 as well. In this instance, the level of access is controlled by the user ID under which Client Access connects (which may be different from the user profile the user signs on with). Many shops, by default, set Client Access to connect with a common user ID.
Suppose a user who connects with Client Access has *CHANGE access to a file, or belongs to a group that does, but is prevented from accessing the file because he is restricted to menu access and is not allowed to access any menu that calls a program that changes the file. This is not as uncommon as it may sound. Many installations make users the members of a group with *CHANGE access for all of an applications database objects and control those users access at the menu level.
As Figure 3 shows, the user I just mentioned can get at the file and modify it using Microsofts Access database management program and the Client Access ODBC driver. This is because ODBC uses the authority of the user profile that Client Access connects with, and, in our example, that profile has *CHANGE authority over the file.
This discussion makes one point very clear: Object-level security is not all that complicated, but its interactions can be. You must give careful thought to how and to whom you grant authorities on your systems.
REFERENCES AND RELATED MATERIALS
An Implementation Guide for AS/400 Security and Auditing: Including C2, Cryptography, Communications, and PC Connectivity, Redbook (GG24-4200-00)
AS/400 Tips and Tools for Securing Your AS/400 (SC41-3300-01, CD-ROM QBKACF01)
OS/400 SecurityReference V4R4 (SC41-5302-03, CD-ROM QB3ALC03)
Security Basic V4R1 (SC41-5301-00, CD-ROM QB3ALB00)
The AS/400 Owners Manual. Mike Dawson. Carlsbad, CA: MC Publishing Co., 1997
Figure 1: An authorization list is a list of users and their specific authorities.
Figure 2: You can control adopted authority with the CHGPGM screen.
Figure 3: Selecting ODBC data sources can allow users inappropriate access to AS/400 objects.