Object Authority, User Profiles, and Adopted Authority: IBM i Security Fundamentals

Security on IBM i isn't a separate concern bolted onto application development — it's woven directly into the object model covered throughout IBM i Platform Foundations, and understanding its fundamentals is essential for any developer working on production systems.

Every object on IBM i carries object authority, which determines who can access it and what they're permitted to do with it once they have access. Authority can be granted broadly or narrowly, to individual users or to groups, and it governs everything from whether a user can view a file's contents to whether they can delete an object outright. This is the mechanism that keeps a payroll file, for instance, accessible to the payroll application but not to every user on the system.

A user profile is the object that represents an individual user's identity on the system, and it's central to how authority is evaluated. A user profile carries its own set of permissions and attributes, determining what that user's jobs are allowed to do across the system. Every job that runs traces back to a user profile, and that profile's authority shapes what the job can access.

Adopted authority is where things get more interesting, and it's a concept that underlies a huge share of how production IBM i applications actually manage security. Normally, a program runs with the authority of the user who called it — but a program can be set up to adopt the authority of its owner instead, temporarily running with that owner's permissions rather than the caller's own. This lets an application grant users access to perform specific, controlled actions — updating a record through a validated business process, for example — without granting those users broad, direct authority to the underlying files themselves.

This pattern shows up constantly in real applications. A user might have no direct authority to update a customer record, but the application program they're using, running with adopted authority, can perform that update on their behalf within the bounds the application enforces. It's a powerful model for keeping direct object access tightly controlled while still letting applications do their job.

Commands like DSPOBJAUT and DSPUSRPRF let a developer inspect exactly who has what authority to a given object, or what a specific user profile is configured to do — turning security from an abstract policy into something concretely checkable.

This lesson is Lesson 11 of IBM i Platform Foundations in IBM i ILE RPG Mastery, closing out the platform fundamentals with the security model every production application depends on.