Object-level Security and Your Applications

IBM i (OS/400, i5/OS)
  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times

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 wait—applications 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/400’s 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 can’t access anything. These can all be applied at the user, group, or authorization-list level.

Why are there so many security features? Good question. I’m sure I don’t 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 department’s 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 object’s owner.

Who owns the object? When the object is first created, the user profile of its creator is the object’s owner. By default, the owner has *ALL authority. That is, the owner can use, change, or delete the object. If the owner’s user profile is deleted, ownership falls to QDFTOWN, the system default. Using the Change Object Owner (CHGOBJOWN) command, you can transfer ownership to another user’s profile or to a group profile. For

example, when I develop an application for my company’s enterprise resource planning (ERP) system, I change its ownership to the group profile associated with the system’s 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 object’s 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. You’ll 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 writing—just reading. For a program or command object, you can call (execute) it, and that’s it.

The fourth specific authority isn’t really an authority at all. *EXCLUDE means that you can’t do anything at all with the object. You might call this setting the antiauthority.

If you don’t have specific authority to an object—that is, if you’re not a security officer or the object’s owner—your authority reverts to whatever *PUBLIC authority is set. The *PUBLIC authority attribute controls the general public’s access to the object. By general public, I mean the system’s users who aren’t specified in an object’s 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 shouldn’t have. There is a downside, however: The tighter your system’s security is, the more time you’ll 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 doesn’t have the authorization list.

Special Authorities

You can also grant special authorities to specific users. While I won’t 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 Owner’s Manual by Mike Dawson.

Adopted Authority—You 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 program’s user profile attribute to either *USER or *OWNER. *USER means that the program uses the user’s authority to access objects. *OWNER means that the program uses its owner’s authority to access objects.

How does this help? Once again, I’ll illustrate with an example. Suppose you have a transaction history file that you want users to be able to add transactions to but you don’t 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 can’t 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 program’s 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 owner’s 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. I’ll 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 user’s authority, your user’s group authority, and public authority.

Take a look at another example. Suppose a file’s 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. There’s no problem—CHGUSR 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! There’s 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 isn’t 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 file’s authority attributes. NONUSR is, therefore, a member of *PUBLIC with respect to the file. NONUSR tries to execute the inquiry program. Ka-boom! There’s a program error. NONUSR has no rights. Go back to adopted authority. Change the inquiry program’s USRPRF attribute to *OWNER and change its ownership to READUSR. NONUSR can now execute the inquiry program.

Things External—Those 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 application’s 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 Microsoft’s 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.

Tread Lightly

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.


• 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 Security—Reference V4R4 (SC41-5302-03, CD-ROM QB3ALC03)

• Security — Basic V4R1 (SC41-5301-00, CD-ROM QB3ALB00)

• The AS/400 Owner’s Manual. Mike Dawson. Carlsbad, CA: MC Publishing Co., 1997

Object-level_Security_and_Your_Applications05-00.png 395x297

Figure 1: An authorization list is a list of users and their specific authorities.

Object-level_Security_and_Your_Applications05-01.png 395x297

Figure 2: You can control adopted authority with the CHGPGM screen.

Object-level_Security_and_Your_Applications06-00.png 406x323

Figure 3: Selecting ODBC data sources can allow users inappropriate access to AS/400 objects.



Support MC Press Online





  • White Paper: Node.js for Enterprise IBM i Modernization

    SB Profound WP 5539

    If your business is thinking about modernizing your legacy IBM i (also known as AS/400 or iSeries) applications, you will want to read this white paper first!

    Download this paper and learn how Node.js can ensure that you:
    - Modernize on-time and budget - no more lengthy, costly, disruptive app rewrites!
    - Retain your IBM i systems of record
    - Find and hire new development talent
    - Integrate new Node.js applications with your existing RPG, Java, .Net, and PHP apps
    - Extend your IBM i capabilties to include Watson API, Cloud, and Internet of Things

    Read Node.js for Enterprise IBM i Modernization Now!


  • Profound Logic Solution Guide

    SB Profound WP 5539More 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 companyare not aligned with the current IT environment.

    Get your copy of this important guide today!


  • 2022 IBM i Marketplace Survey Results

    Fortra2022 marks the eighth edition of the IBM i Marketplace Survey Results. Each year, Fortra captures data on how businesses use the IBM i platform and the IT and cybersecurity initiatives it supports.

    Over the years, this survey has become a true industry benchmark, revealing to readers the trends that are shaping and driving the market and providing insight into what the future may bring for this technology.

  • Brunswick bowls a perfect 300 with LANSA!

    FortraBrunswick is the leader in bowling products, services, and industry expertise for the development and renovation of new and existing bowling centers and mixed-use recreation facilities across the entertainment industry. However, the lifeblood of Brunswick’s capital equipment business was running on a 15-year-old software application written in Visual Basic 6 (VB6) with a SQL Server back-end. The application was at the end of its life and needed to be replaced.
    With the help of Visual LANSA, they found an easy-to-use, long-term platform that enabled their team to collaborate, innovate, and integrate with existing systems and databases within a single platform.
    Read the case study to learn how they achieved success and increased the speed of development by 30% with Visual LANSA.


  • The Power of Coding in a Low-Code Solution

    LANSAWhen it comes to creating your business applications, there are hundreds of coding platforms and programming languages to choose from. These options range from very complex traditional programming languages to Low-Code platforms where sometimes no traditional coding experience is needed.
    Download our whitepaper, The Power of Writing Code in a Low-Code Solution, and:

    • Discover the benefits of Low-code's quick application creation
    • Understand the differences in model-based and language-based Low-Code platforms
    • Explore the strengths of LANSA's Low-Code Solution to Low-Code’s biggest drawbacks



  • Why Migrate When You Can Modernize?

    LANSABusiness 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.
    In this white paper, you’ll learn how to think of these issues as opportunities rather than problems. We’ll explore motivations to migrate or modernize, their risks and considerations you should be aware of before embarking on a (migration or modernization) project.
    Lastly, we’ll discuss how modernizing IBM i applications with optimized business workflows, integration with other technologies and new mobile and web user interfaces will enable IT – and the business – to experience time-added value and much more.


  • UPDATED: Developer Kit: Making a Business Case for Modernization and Beyond

    Profound Logic Software, Inc.Having trouble getting management approval for modernization projects? The problem may be you're not speaking enough "business" to them.

    This Developer Kit provides you study-backed data and a ready-to-use business case template to help get your very next development project approved!

  • What to Do When Your AS/400 Talent Retires

    FortraIT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators is small.

    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:

    • Why IBM i skills depletion is a top concern
    • How leading organizations are coping
    • Where automation will make the biggest impact


  • Node.js on IBM i Webinar Series Pt. 2: Setting Up Your Development Tools

    Profound Logic Software, Inc.Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application. In Part 2, Brian May teaches you the different tooling options available for writing code, debugging, and using Git for version control. Attend this webinar to learn:

    • Different tools to develop Node.js applications on IBM i
    • Debugging Node.js
    • The basics of Git and tools to help those new to it
    • Using as a pre-built development environment



  • Expert Tips for IBM i Security: Beyond the Basics

    SB PowerTech WC GenericIn this session, IBM i security expert Robin Tatam provides a quick recap of IBM i security basics and guides you through some advanced cybersecurity techniques that can help you take data protection to the next level. Robin will cover:

    • Reducing the risk posed by special authorities
    • Establishing object-level security
    • Overseeing user actions and data access

    Don't miss this chance to take your knowledge of IBM i security beyond the basics.



  • 5 IBM i Security Quick Wins

    SB PowerTech WC GenericIn today’s threat landscape, upper management is laser-focused on cybersecurity. You need to make progress in securing your systems—and make it fast.
    There’s no shortage of actions you could take, but what tactics will actually deliver the results you need? And how can you find a security strategy that fits your budget and time constraints?
    Join top IBM i security expert Robin Tatam as he outlines the five fastest and most impactful changes you can make to strengthen IBM i security this year.
    Your system didn’t become unsecure overnight and you won’t be able to turn it around overnight either. But quick wins are possible with IBM i security, and Robin Tatam will show you how to achieve them.

  • Security Bulletin: Malware Infection Discovered on IBM i Server!

    SB PowerTech WC GenericMalicious programs can bring entire businesses to their knees—and IBM i shops are not immune. It’s critical to grasp the true impact malware can have on IBM i and the network that connects to it. Attend this webinar to gain a thorough understanding of the relationships between:

    • Viruses, native objects, and the integrated file system (IFS)
    • Power Systems and Windows-based viruses and malware
    • PC-based anti-virus scanning versus native IBM i scanning

    There are a number of ways you can minimize your exposure to viruses. IBM i security expert Sandi Moore explains the facts, including how to ensure you're fully protected and compliant with regulations such as PCI.



  • Encryption on IBM i Simplified

    SB PowerTech WC GenericDB2 Field Procedures (FieldProcs) were introduced in IBM i 7.1 and have greatly simplified encryption, often without requiring any application changes. Now you can quickly encrypt sensitive data on the IBM i including PII, PCI, PHI data in your physical files and tables.
    Watch this webinar to learn how you can quickly implement encryption on the IBM i. During the webinar, security expert Robin Tatam will show you how to:

    • Use Field Procedures to automate encryption and decryption
    • Restrict and mask field level access by user or group
    • Meet compliance requirements with effective key management and audit trails


  • Lessons Learned from IBM i Cyber Attacks

    SB PowerTech WC GenericDespite the many options IBM has provided to protect your systems and data, many organizations still struggle to apply appropriate security controls.
    In this webinar, you'll get insight into how the criminals accessed these systems, the fallout from these attacks, and how the incidents could have been avoided by following security best practices.

    • Learn which security gaps cyber criminals love most
    • Find out how other IBM i organizations have fallen victim
    • Get the details on policies and processes you can implement to protect your organization, even when staff works from home

    You will learn the steps you can take to avoid the mistakes made in these examples, as well as other inadequate and misconfigured settings that put businesses at risk.



  • The Power of Coding in a Low-Code Solution

    SB PowerTech WC GenericWhen it comes to creating your business applications, there are hundreds of coding platforms and programming languages to choose from. These options range from very complex traditional programming languages to Low-Code platforms where sometimes no traditional coding experience is needed.
    Download our whitepaper, The Power of Writing Code in a Low-Code Solution, and:

    • Discover the benefits of Low-code's quick application creation
    • Understand the differences in model-based and language-based Low-Code platforms
    • Explore the strengths of LANSA's Low-Code Solution to Low-Code’s biggest drawbacks



  • The Biggest Mistakes in IBM i Security

    SB Profound WC Generic The Biggest Mistakes in IBM i Security
    Here’s the harsh reality: cybersecurity pros have to get their jobs right every single day, while an attacker only has to succeed once to do incredible damage.
    Whether that’s thousands of exposed records, millions of dollars in fines and legal fees, or diminished share value, it’s easy to judge organizations that fall victim. IBM i enjoys an enviable reputation for security, but no system is impervious to mistakes.
    Join this webinar to learn about the biggest errors made when securing a Power Systems server.
    This knowledge is critical for ensuring integrity of your application data and preventing you from becoming the next Equifax. It’s also essential for complying with all formal regulations, including SOX, PCI, GDPR, and HIPAA
    Watch Now.

  • Comply in 5! Well, actually UNDER 5 minutes!!

    SB CYBRA PPL 5382

    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.

    Request your trial now!

  • Backup and Recovery on IBM i: Your Strategy for the Unexpected

    FortraRobot automates the routine 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:
    - Simplified backup procedures
    - Easy data encryption
    - Save media management
    - Guided restoration
    - Seamless product integration
    Make sure your data survives when catastrophe hits. Try the Robot Backup and Recovery Solution FREE for 30 days.

  • Manage IBM i Messages by Exception with Robot

    SB HelpSystems SC 5413Managing messages on your IBM i can be more than a full-time job if you have to do it manually. How can you be sure you won’t miss important system events?
    Automate your message center with the Robot Message Management Solution. Key features include:
    - Automated message management
    - Tailored notifications and automatic escalation
    - System-wide control of your IBM i partitions
    - Two-way system notifications from your mobile device
    - Seamless product integration
    Try the Robot Message Management Solution FREE for 30 days.

  • Easiest Way to Save Money? Stop Printing IBM i Reports

    FortraRobot automates report bursting, distribution, bundling, and archiving, and offers secure, selective online report viewing.
    Manage your reports with the Robot Report Management Solution. Key features include:

    - Automated report distribution
    - View online without delay
    - Browser interface to make notes
    - Custom retention capabilities
    - Seamless product integration
    Rerun another report? Never again. Try the Robot Report Management Solution FREE for 30 days.

  • Hassle-Free IBM i Operations around the Clock

    SB HelpSystems SC 5413For over 30 years, Robot has been a leader in systems management for IBM i.
    Manage your job schedule with the Robot Job Scheduling Solution. Key features include:
    - Automated batch, interactive, and cross-platform scheduling
    - Event-driven dependency processing
    - Centralized monitoring and reporting
    - Audit log and ready-to-use reports
    - Seamless product integration
    Scale your software, not your staff. Try the Robot Job Scheduling Solution FREE for 30 days.