Adopted Authority and Performance

Q: How does authority checking work with multiple groups?

A: If OS/400 does not find any authorities at the user level, it goes on to check a user's group profiles' authority to the object. When a user is a member of only one group, the check is just like at the user level. If the group profile has some authority to the object being accessed and it is sufficient for the function being performed, the user gets access to the object. If the user doesn't have sufficient authority, OS/400 stops the authority checking and the user does not get access to the object.

When attempting to perform a function, such as a database open, the system--SLIC (System Licensed Internal Code) to be exact--first checks to see if the process has the authority required to execute the MI instruction. Part of the definition of each machine interface (MI) instruction is the authority required to run the instruction. If the process does not have sufficient authority, the MI instruction will not execute.

Here's a pseudo code flow of how OS/400 checks authority:

Step 1a:    IF user has *ALLOBJ
                THEN user has sufficient authority and gains access
                ELSE checking continues on to Step 1b

Step 1b:    IF user has a private authority to the object being accessed and the private authority is sufficient
                THEN user has sufficient authority and gains access
                ELSE IF user has some authority but not sufficient
                THEN user is denied access and checking STOPS
                ELSE user has no authority and checking continues on to Step 1c

Step 1c:    IF object is secured by an authorization list and user has authority to the authorization list and the authority is sufficient
                THEN user has sufficient authority and gains access
                ELSE IF user has some authority but not sufficient
                THEN user is denied access and checking STOPS
                ELSE user has no authority or the object is not secured by an authorization list, so checking continues on to Step 2a

Step 2a:    IF the user's group has *ALLOBJ
                THEN user has authority and gains access
                ELSE checking continues on to Step 2b

Step 2b:    IF the user's group is the primary group for the object and the primary group authority is sufficient
                THEN user has sufficient authority (via his group's primary group authority), and user gains access
                ELSE IF group has some authority, but it is not sufficient
                THEN user is denied access and checking STOPS
                ELSE user doesn't have a group or the group is not the primary group for the object, so checking continues on to Step 2c.

Step 2c:    IF the user's group has a private authority to the object being accessed and the private authority is sufficient
                THEN user has sufficient authority (via his group), and user gains access
                ELSE IF group has some authority, but it is not sufficient
                THEN user is denied access, and checking STOPS
                ELSE user doesn't have a group or the group does not have a private authority, so checking continues on to Step 2d

Step 2d:    IF object is secured by an authorization list and group has authority to the authorization list and the authority is sufficient
                THEN user has sufficient authority (from his group's authority to the authorization list), and user gains access
                ELSE IF group has some authority, but it is not sufficient
                THEN user is denied access, and checking STOPS
                ELSE group has no authority or the object is not secured by an authorization list, so checking continues on to Step 3a

Step 3a:    IF object's *PUBLIC authority is sufficient
                THEN user gains access
                ELSE IF *PUBLIC is not sufficient
                THEN user is denied access, and checking STOPS
                ELSE object is secured by authorization list and *PUBLIC authority comes from authorization list, so checking continues on to Step 3b

Step 3b:    IF authorization list's *PUBLIC authority is sufficient
                THEN user gains access and checking stops
                ELSE user is denied access


This flow assumes that the user has only one group. For an explanation of how OS/400 handles authority checking and multiple groups, see the topic Authority Checking with Multiple Groups in a previous column.

Primary Group Authority

Before we go through some of the questions I've been asked, I'd like to ask all of you a question: How many of you know what primary group authority (being processed in Step 2b) is? Hmmmm. I'm not seeing many hands being raised, so let me explain. Primary group authority is one of the authorities (like *PUBLIC and owner's authorities) that are stored with the object itself. It can only be given to a group profile. In fact, for every object, only one group profile can have primary group authority. For a user to get authority through primary group authority, one of her groups must be the primary group of the object. Contrary to the belief of the few people that know about this authority, this group does not need to be the user's first group profile. It can be one of her supplemental groups. As you might have guessed, this authority is rarely implemented. It was added to OS/400 in V3R1 to accommodate a UNIX concept and to aid in the porting of UNIX applications to OS/400.

Now let's look at those questions.

*ALLOBJ Authority

Q: I have granted programmers private authority *EXCLUDE to all of the critical files on our production system, yet I've discovered that they are still able to update files directly without going through the appropriate change management process. Does the fact that they have *ALLOBJ have anything to do with this?

A: Let's walk through the pseudo code. Take a look at Step 1a. When the user has *ALLOBJ authority, the user gains access to the object. As you can see, the processing does not continue on to Step 1b, so the private authority is never checked in this case. Once you give *ALLOBJ special authority, you cannot control what that user accesses.

Private Authority vs. Authorization Lists

Q: Which takes precedence, private authorities or authority to an authorization list?

A: The answer depends on who has the private authority and who has the authority to the authorization list. Let's run a couple of scenarios. If a user has private authority to the object as well as authority to the authorization list, the private authority will be processed in Step 1b and the system will never get to Step 1c to process the authorization list. If a user's group has a private authority and the user has the authority to the authorization list, the authorization list authority will be processed in Step 1c and the system will never get to Step 2c to process the group's private authority.

Adopted Authority

Q: Where does adopted authority get processed in OS/400's authority checking algorithm?

A: OS/400 will first run a normal authority check, just as if adopted authority wasn't a factor. If sufficient authority is found, adopted authority is never checked. If sufficient authority is not found, OS/400 checks to see if any of the programs in the program call stack are adopting authority. If so, OS/400 will perform Steps 1a–1c, looking to see if the owner of the program has the required authority. If there are multiple programs in the call stack that adopt, OS/400 will perform Steps 1a–1c for each program owner until it either finds sufficient authority or runs out of programs that adopt.

Let's look at an example. Say that Abby is trying access a database file and is opening it for update. To do that successfully, she needs *CHANGE authority. OS/400 runs Steps 1a–1c, and for the sake of this example, we'll say that no authority is found at the user level. OS/400 goes on to look at Abby's group profile. In Step 2c, OS/400 finds that Abby's group profile has a private authority of *USE to the database file. Normally, Abby would receive a "Not authorized" message and be denied access because *USE authority is less authority than *CHANGE. But because a program in the stack adopts authority, OS/400 checks that program's owner to see if that profile has sufficient authority to the database file. Lo and behold, the program owner has *CHANGE authority to the database file, and Abby's quest to open the database file for update is successful.

OS/400 Authority Checking and Performance Considerations

Given the explanation above, one might think that authority checking must be a real performance hog on OS/400, but that's not the case. In fact, numerous performance enhancements have been put in over the years to ensure that that's not the case.

*PUBLIC Authority and Performance

Since *PUBLIC authority is the last authority checked, you may wonder about performance when the authority comes from *PUBLIC. Actually, this can be a very fast check. That's because of two attributes that are maintained with each object and used during authority checking. One attribute is an indication of whether there are any private authorities for the object. If there are no private authorities and the object is not secured by an authorization list, then OS/400 bypasses most of the authority checking and jumps right to the *PUBLIC authority check. *PUBLIC authority is stored with the object, so checking *PUBLIC authority is very fast. The other attribute indicates whether there are any private authorities "less than" or "more restrictive than" the object's *PUBLIC authority. If there aren't, OS/400 once again skips around much of the algorithm and immediately checks *PUBLIC authority.

Private Authority and Performance

Take the case where a user gets authority to access an object via private authority. As an example, let's say that *PUBLIC authority for the object is *EXCLUDE and that the private authority is *CHANGE. To help the performance of this configuration, OS/400 creates authority caches for users the first time they access an object, and the authority comes from private authority or from an authorization list. The cache holds up to 32 private authorities and up to 32 private authorities to authorization lists. If a user repeatedly accesses the same objects, the user's private authority will come from the cache. This is a very fast check.

Primary Group Authority and Performance

As explained earlier, primary group authority is stored in the header of the object. Performance for any authority that is stored with the object is a very fast check. About the only reason for traditional OS/400 applications to use primary group authority is to speed up the authority check. There is a slight, and I do mean slight, advantage to having authority coming from primary group authority vs. giving the group a private authority.

Adopted Authority and Performance

Adopted authority used to be a bit of a drag on applications until a few releases ago. Now, when the program owner is also the owner of the object being accessed, the check is very fast. It is still a bit of a drain when the program owner is not the owner but rather, has a private authority to the object. This, however, is the more secure configuration.

Hopefully, you now have a better understanding of OS/400's authority checking algorithm as well as a clearer picture of the performance aspects of authority checking. The message I want you to remember however, is this: As long as an authority scheme is easily explained, maintained, and documented, you shouldn't be worried about performance. Given all of the performance enhancements the good folks in Rochester have added along with the sheer speed of today's processors, you have to try--hard--to create a performance issue that you can attribute to your security scheme.

If you would like to submit a question for possible inclusion in a future "Security Patrol," please send it to This email address is being protected from spambots. You need JavaScript enabled to view it.. Make sure to put "Security Patrol Question" in the Subject line.

Carol Woodbury is co-author of the book Implementing AS/400 Security as well as co-founder of SkyView Partners, a firm specializing in security consulting and services. Carol has 13 years in the security industry, 10 of those working for IBM's Enterprise Server Group as the AS/400 Security Architect and Chief Engineering Manager of Security Technology. Carol can be reached at This email address is being protected from spambots. You need JavaScript enabled to view it..

 

Carol Woodbury is IBM i Security SME and Senior Advisor to Kisco Systems, a firm focused on providing IBM i security solutions. Carol has over 30 years’ experience with IBM i security, starting her career as Security Team Leader and Chief Engineering Manager for iSeries Security at IBM in Rochester, MN. Since leaving IBM, she has co-founded two companies: SkyView Partners and DXR Security. Her practical experience and her intimate knowledge of the system combine for a unique viewpoint and experience level that cannot be matched.

Carol is known worldwide as an author and award-winning speaker on security technology, specializing in IBM i security topics. She has written seven books on IBM i security, including her two current books, IBM i Security Administration and Compliance, 3^rd Edition and Mastering IBM i Security, A Modern, Step-by-Step Approach. Carol has been named an IBM Champion since 2018 and holds her CISSP and CRISC security certifications.

---

MC Press books written by Carol Woodbury available now on the MC Press Bookstore.

		IBM i Security Administration and Compliance: Third Edition Don't miss the newest edition by the industry’s #1 IBM i security expert. List Price $71.95 Now On Sale
		Mastering IBM i Security Get the must-have guide by the industry’s #1 security authority. List Price $49.95 Now On Sale

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