Category: Authorization Concepts

Action

Simply put

In identity and access management, an 'action' typically refers to the specific operation a user or system wants to perform on a resource, such as reading a file, editing a record, or deleting an account. When someone requests access, the system evaluates whether that particular action is permitted for that requester on that resource. The action is one part of an access decision, alongside who is requesting and what they are trying to reach.

Formal definition

The evidence packet provided contains no sources relevant to the IAM sense of 'Action' (the referenced sources describe the Action retail discounter and various action films/media), so an authoritative technical definition cannot be grounded in the supplied evidence. In general IAM usage, an action denotes the operation component of an authorization request, commonly modeled as one element of a subject-action-resource-context tuple evaluated by a policy decision point (PDP) against an access control policy. In policy-based and attribute-based access control (PBAC/ABAC), actions are frequently expressed as verbs (for example read, write, delete) and matched against policy rules; the precise representation, granularity, and vocabulary of actions depend on the policy model, standard profile, and vendor implementation. Note: the specifics above are general IAM background and are not derived from the provided sources, which are out of scope for this term.

Why it matters

The action is one of the core inputs to any authorization decision, and getting it right determines whether access control is meaningful or merely decorative. A system that authenticates a user correctly but fails to distinguish between reading a record and deleting it cannot enforce least privilege in any practical sense. Precise action modeling is what allows policies to express the difference between a support agent who may view an account and an administrator who may close one, even when both are operating on the same resource.

Because the action sits alongside the subject, the resource, and contextual attributes in an access request, imprecise or overly coarse action definitions tend to push deployments toward broad, hard-to-audit grants. When actions are lumped together, segregation of duties becomes difficult to certify and access reviews lose granularity, since reviewers cannot easily see which specific operations a given grant actually permits. Fine-grained, well-named actions, by contrast, make policies more expressive and access decisions more auditable.

The way actions are represented is not standardized across the field. Vocabulary, granularity, and matching semantics vary by policy model, standard profile, and vendor implementation, so an 'action' in one system may not map cleanly to an 'action' in another. This variability matters most during integration and migration, where mismatched action taxonomies can silently widen or narrow effective permissions.

Who it's relevant to

Security architects

Architects designing authorization systems must decide how actions are named, scoped, and grouped, since this taxonomy shapes how expressive and auditable the resulting policies can be. Coarse action definitions tend to force broad grants, while fine-grained actions support least privilege at the cost of added modeling effort.

IAM engineers

Engineers implementing PBAC or ABAC policies work directly with actions as one element of the subject-action-resource-context tuple evaluated by the PDP. Because action vocabulary and matching semantics vary by vendor and policy model, engineers must confirm how a given platform represents and interprets actions rather than assuming portability across systems.

Identity governance leads

Governance leads rely on well-defined actions to make access reviews and segregation-of-duties analysis meaningful. When actions are too coarse, reviewers cannot see which specific operations a grant permits, which weakens certification. Fine-grained action definitions improve the granularity of what can be reviewed and attested.

Compliance officers

Compliance officers assessing whether controls enforce least privilege depend on the ability to distinguish permitted operations at the action level. Auditable, specific actions make it easier to demonstrate that access is limited to the operations each role or attribute set actually requires.

Inside Action

Action identifier

The name or verb that designates the operation a principal seeks to perform on a resource (for example, read, write, delete, approve). In authorization decisions, the action is one of the core inputs a policy decision point (PDP) evaluates alongside the subject, resource, and environment/context.

Subject-action-resource triple

In most access control models, an authorization request is expressed as a combination of who (subject), what operation (action), and on what (resource). The action component specifies the requested operation and is distinct from the identity of the requester and the target object.

Action in policy models

How an action is represented depends on the access control model. In RBAC, actions are typically bundled into permissions assigned to roles; in ABAC/PBAC, actions are matched against policy rules that may also evaluate subject, resource, and environment attributes; in ReBAC, an action is permitted based on a relationship path between subject and resource.

Action mapping to protected operations

Actions are typically mapped to concrete operations exposed by an application or API (for example, an HTTP method, a business function, or an API scope). The granularity of this mapping varies by deployment and affects how precisely access can be controlled.

Enforcement context

The action is evaluated at runtime as part of an authorization decision. A policy enforcement point (PEP) intercepts the attempted action, a PDP renders the decision, and policy information points (PIPs) may supply attributes used to evaluate whether that action is permitted. This is an enforcement concern, separate from governance activities that define what actions a role or entitlement should permit.

Common questions

Answers to the questions practitioners most commonly ask about Action.

Is an action the same thing as a permission?

No. An action is the specific operation a principal attempts to perform on a resource (for example, read, write, delete, or approve), whereas a permission is the granted right that authorizes a principal to perform a given action on a resource. The action is one component evaluated during authorization; the permission expresses whether that action is allowed. Conflating the two blurs the request (what is being attempted) with the grant (what is permitted).

Does defining actions belong to authentication or authorization?

Actions are an authorization concern, not an authentication one. Authentication verifies who the principal is; authorization determines what that principal may do, and the action is the operation being evaluated at that authorization step. A system first identifies and authenticates the principal, then evaluates whether the requested action on a resource is permitted. Actions play no role in verifying identity itself.

How are actions typically expressed in ABAC or PBAC policies?

In attribute-based and policy-based access control, the action is usually one of the inputs a policy decision point (PDP) evaluates alongside subject, resource, and environment attributes. Depending on the policy language and deployment, actions may be represented as discrete verbs, hierarchical action sets, or attribute-tagged operations. The exact representation varies by vendor and policy engine, so the granularity and naming conventions should be confirmed against the specific implementation.

How should actions be modeled when mapping to roles in an RBAC system?

In role-based access control, actions are typically bundled into permissions that are assigned to roles, and roles are then assigned to principals. When modeling, teams often define the set of allowable actions per resource type first, then group related actions into permissions that reflect meaningful job functions. Overly coarse action grouping can weaken least privilege, while excessive granularity can complicate administration; the balance depends on the deployment's governance requirements.

How do actions relate to the PDP and PEP at runtime?

At runtime, the policy enforcement point (PEP) intercepts a request and passes the requested action, along with subject and resource context, to the policy decision point (PDP) for evaluation. The PDP returns a decision, and the PEP enforces it by permitting or denying the action. The action is therefore part of the decision request rather than something the enforcement components define; how it is transmitted and structured depends on the protocol and integration in use.

How can defined actions support access reviews and segregation of duties?

In identity governance and administration, the actions associated with permissions and roles can inform access certification and segregation-of-duties (SoD) analysis. Reviewers can assess whether a principal's granted actions on sensitive resources are appropriate, and SoD policies can flag combinations of actions that should not coexist for one principal. This is a lifecycle governance use of action definitions and is distinct from the real-time enforcement of individual action requests.

Common misconceptions

An action is the same thing as a permission or an entitlement.

An action is the requested operation itself (for example, delete). A permission or entitlement typically binds an action to a resource and, in RBAC, to a role. The action is one element of that binding, not the binding as a whole.

Defining allowed actions is an authentication concern.

Deciding which actions a principal may perform is authorization, which occurs after the principal has been identified and authenticated. Authentication establishes who the principal is and says nothing about which actions are permitted.

Actions are always coarse-grained, high-level operations.

Action granularity varies by deployment and by the policy model in use. Depending on configuration, an action can be as broad as a business function or as narrow as a single API operation; the appropriate granularity is a design decision, not a fixed property.

Best practices

Define actions with a granularity that matches the operations you actually need to control, and document how each action maps to concrete application or API operations to avoid ambiguity between policy authors and enforcement points.

Keep action definitions consistent across the systems that reference them so the same operation is not represented under conflicting names in different policies or services.

Evaluate actions at runtime through a clearly separated PEP/PDP flow, and treat which actions are grantable as a governance decision handled through provisioning, entitlement definition, and access reviews.

Choose an action representation appropriate to your access control model (permissions in RBAC, rule-matched actions in ABAC/PBAC, relationship-gated actions in ReBAC) rather than forcing one style across all systems.

Include actions in segregation-of-duties analysis where combinations of permitted operations create risk, so that conflicting actions are detected during certification.

Review action-to-resource mappings periodically to ensure they still reflect the operations exposed by evolving applications and APIs, since drift can silently widen or narrow effective access.