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
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
Carol Woodbury is President and CTO of DXR Security and has over 30 years’ experience with IBM i Security. She started 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 current company - DXR Security - specializes in penetration testing for IBM i. Her practical experience together with her intimate knowledge of the system combine for a unique viewpoint and experience level that cannot be matched.
Carol is known world-wide 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. 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
|
 |
|
IBM i Security Administration and Compliance: Second Edition Get the must-have guide by the industry’s #1 security authority. List Price $71.95 Now On Sale
|
|
||
 |
|
IBM i Security Administration and Compliance For beginners to veterans, this is the definitive security resource. List Price $69.95
Now On Sale
|
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online