Category: Authorization Concepts

Object

Also known as: resource, protected resource, target

Simply put

In access control, an object is the thing being protected and accessed, such as a file, database record, application, or system function. Access decisions govern whether a subject (a user, service, or other actor) is allowed to perform a particular action on an object. Note: the evidence packet provided contains only general dictionary, grammatical, and legal definitions of the word 'object' and no IAM-specific sources, so the access-control meaning below reflects standard usage but cannot be cited to the supplied evidence.

Formal definition

In an access control system, an object is the entity or resource on which an operation is requested and for which authorization is evaluated, for example, a file, API endpoint, directory entry, table row, or administrative operation. Objects are paired with subjects (the principals requesting access) and actions (the operations requested) to form the basic triad evaluated by access control models: in RBAC via role-to-permission assignments over objects, in ABAC/PBAC via policies over object attributes, and in ReBAC via relationships between subjects and objects. Objects are the target of authorization decisions and should not be conflated with subjects; identifying the object and its attributes is typically a policy information point (PIP) concern feeding the policy decision point (PDP), while enforcement of the granted or denied access occurs at the policy enforcement point (PEP). The precise definition, granularity, and attribute model of an object vary by system and deployment context. This term's access-control sense is not attested in the supplied evidence, which addresses only the general-language meanings of 'object.'

Why it matters

The object is one of the three anchors of every access control decision, alongside the subject and the action, and getting its definition and granularity right determines whether a system can enforce least privilege at all. If objects are defined too coarsely (for example, granting access to an entire database rather than specific records), authorization becomes blunt and over-permissive; if defined too finely without a coherent attribute model, policies become unmanageable. Precisely identifying what is being protected is therefore the starting point for any meaningful authorization design.

Conflating objects with subjects is a common source of confusion in access modeling, particularly in systems where an entity can be both, for instance, a service account that is a subject when it calls an API but an object when its own configuration is the target of an administrative operation. Keeping the roles distinct in policy language is essential to avoid ambiguous or self-referential rules. Because the definition, granularity, and attribute model of an object vary by system and deployment context, teams should treat object modeling as a deliberate design activity rather than an implicit byproduct of choosing a product.

Note that the evidence supplied for this entry contains only general dictionary, grammatical, and legal definitions of the word 'object' and no IAM-specific sources. The access control usage described here reflects standard industry practice but is not attested by the provided evidence, and readers should validate specifics against their own platform documentation.

Who it's relevant to

Security architects

Architects define what constitutes a protectable object in a system and at what granularity, shaping whether authorization can express least privilege. Deciding whether the object is a whole application, an API endpoint, or an individual record directly affects the expressiveness and maintainability of the resulting access model.

IAM engineers

Engineers implement the subject-action-object triad in policy and enforcement code, wiring object identification and attribute retrieval into the PIP, PDP, and PEP flow. They must keep objects and subjects distinct in policy language, especially for entities that act as both depending on the request.

Access governance and compliance leads

Governance and compliance stakeholders review who has access to which objects and rely on clear object definitions to scope access certifications, entitlement reviews, and segregation-of-duties analysis. Ambiguous or overly coarse object modeling undermines the accuracy of these lifecycle activities.

System administrators

Administrators map real resources, files, directory entries, database tables, and administrative operations, onto the objects recognized by the access control system. Accurate mapping ensures that granted or denied decisions align with the actual resources users and services attempt to reach.

Inside Object

Object identifier

A unique reference (such as a distinguished name in LDAP, a resource ID, or a URI) that names the object being acted upon within an access control decision or directory.

Attributes

Properties associated with the object (for example classification, owner, sensitivity, or resource type) that policies may evaluate, particularly in ABAC and PBAC models.

Resource or target role

In an access control flow, the object is the resource or entity the subject seeks to act upon; it is distinct from the subject (the requesting principal) and the action (the operation requested).

Relationships

In ReBAC, the object participates in relationships (such as owner, parent, or member) with subjects and other objects, and those relationships can drive authorization decisions.

Directory representation

In directory contexts such as LDAP, an object is an entry defined by object classes and attributes, organized within a hierarchical structure.

Common questions

Answers to the questions practitioners most commonly ask about Object.

Is an object the same thing as a subject in access control?

No. A subject is the active entity (a user, service, or process) that initiates a request, while an object is the passive resource being acted upon, such as a file, database record, API endpoint, or directory entry. The distinction matters because authorization decisions typically evaluate what a given subject may do to a given object. Note that in some cases an entity can be a subject in one operation and an object in another (for example, a user account being read or modified by an administrator), so the roles are relative to a specific access request rather than fixed properties.

Does controlling access to an object happen during authentication?

No. Authentication verifies who the requesting subject is; deciding whether that subject may act on an object is authorization, which is a separate step that typically follows authentication. Identification, authentication, and authorization remain distinct: an object's access rules are evaluated at the authorization stage, usually against the identity and attributes established earlier. Conflating the two obscures where object-level protection is actually enforced.

How are objects represented when defining access policies?

This varies by access control model and deployment. In RBAC, objects are typically grouped and mapped to permissions assigned to roles. In ABAC or PBAC, objects are described by attributes (such as classification, owner, or resource type) that policies evaluate at request time. In ReBAC, objects participate in relationship graphs (for example, a document related to a folder related to a user). The representation you choose depends on the policy model your PDP supports and how granular your resources are.

How does a runtime enforcement flow use object information to reach a decision?

In most deployments, a Policy Enforcement Point (PEP) intercepts the request and forwards the subject, action, and target object to a Policy Decision Point (PDP). The PDP evaluates applicable policies, often pulling additional object attributes from a Policy Information Point (PIP). Object attributes such as sensitivity, ownership, or state can therefore influence the permit or deny decision at request time. The exact division of labor depends on your architecture and the policy model in use.

Where do object definitions fit relative to identity governance concerns?

Object definitions intersect with, but are distinct from, IGA processes. Governance activities such as access reviews, certification campaigns, and segregation-of-duties checks often reference which subjects hold access to which objects, so accurate object inventories and ownership metadata support those reviews. However, defining and cataloging objects for governance is a lifecycle and administration concern, whereas evaluating access to an object per request is a runtime enforcement concern. Keeping the two separated helps avoid blurring who reviews access from what enforces it.

How should object granularity be chosen when designing an access model?

Granularity is a design trade-off that depends on your requirements. Coarse-grained objects (for example, an entire application or a whole directory subtree) simplify administration but limit precision, while fine-grained objects (individual records, fields, or API operations) enable tighter control at the cost of more policies and metadata to manage. Depending on configuration and the model you adopt, attribute- or relationship-based approaches can reduce the policy explosion that fine-grained RBAC sometimes produces. Choose granularity based on the sensitivity of the resources and the review and enforcement burden your organization can sustain.

Common misconceptions

The object and the subject are interchangeable terms in access control.

They are distinct. The subject is the principal requesting access (verified through authentication), while the object is the resource being acted upon. Authorization determines what a given subject may do to a given object; conflating the two obscures the access flow.

An object's attributes are only relevant in RBAC.

In RBAC, decisions typically center on roles assigned to subjects. Object attributes are more central to ABAC and PBAC, where policies evaluate properties of the object (and often the subject and environment) at decision time. The relevance of object attributes depends on the access control model in use.

Defining an object is a governance/lifecycle task rather than a runtime concern.

Object modeling touches both. How objects are provisioned, cataloged, and reviewed is an IGA concern, while evaluating an object against policy at request time is a runtime enforcement concern handled by a PDP/PEP. The two should not be blurred.

Best practices

Model objects, subjects, and actions as distinct elements so that authorization policies clearly express what a subject may do to a given object.

Choose the access control model whose treatment of objects fits the requirement: use object attributes for ABAC/PBAC decisions and object relationships for ReBAC, rather than forcing one model onto all resources.

Assign stable, unique identifiers to objects and keep them consistent across directories, provisioning (for example SCIM), and enforcement points to avoid ambiguity during policy evaluation.

Tag objects with the attributes your policies actually evaluate (such as classification or owner) and govern those attributes through access reviews and certification so policy inputs remain accurate.

Separate the lifecycle management of objects (provisioning, cataloging, review) from runtime evaluation of objects by the PDP/PEP, and document which system owns each responsibility.

Validate that object attributes and relationships supplied to the PDP come from a trusted PIP or source, since authorization outcomes depend on the integrity of those inputs.