Category: Authorization Concepts

Permission

Also known as: Entitlement, Privilege, Access right

Simply put

A permission is the ability to perform a specific action on a specific resource, such as reading a file or editing a record. In everyday terms it reflects the general idea of allowing someone to do something, but in identity systems it is a concrete, granular grant rather than a vague consent. Permissions define what a principal is allowed to do once their identity has been verified.

Formal definition

A permission is a discrete authorization primitive that couples an allowed operation (for example, read, write, delete) with a target object or resource, defining what a principal may do after identification and authentication have completed. Permissions are enforced at the authorization stage and are typically aggregated into higher-level constructs depending on the access control model in use: in RBAC they are assigned to roles which are then granted to subjects, while in ABAC or PBAC the effective set of permitted actions is derived at evaluation time from attributes and policy rather than statically pre-bound. Note that a permission expresses only the granted capability; the runtime decision to allow or deny a given request is made by a policy decision point and applied by a policy enforcement point, and the terminology and granularity of permissions vary by vendor and deployment context.

Why it matters

Permissions are the atomic unit of authorization, and the correctness of an entire access control system ultimately rests on whether the right principals hold the right permissions on the right resources. When permissions accumulate beyond what a principal actually needs, the result is over-entitlement and privilege creep, which expand the blast radius of any compromised account. Because permissions define concrete capabilities rather than vague consent, they are the primary object of access reviews, certifications, and least-privilege analysis in identity governance.

The granularity and clarity of permissions directly affect both security posture and auditability. A permission model that is too coarse forces administrators to grant more than necessary, while one that is excessively fine-grained can become unmanageable and error-prone. In most deployments, permissions are not assigned directly to individuals but aggregated into higher-level constructs such as roles or derived at evaluation time from policy, which shifts the challenge from granting individual rights to reasoning about how those aggregations resolve to effective access.

It is worth emphasizing that a permission expresses only a granted capability; it does not by itself make an allow-or-deny decision. Conflating the existence of a permission with the runtime enforcement of it is a common source of confusion, and understanding the separation between the two is essential for anyone auditing why a particular request succeeded or failed.

Who it's relevant to

IAM Engineers and Security Architects

They design how permissions are modeled, aggregated, and enforced, choosing between RBAC role assignments, ABAC or PBAC policy evaluation, or a hybrid. Getting permission granularity right shapes both the manageability and the security of the resulting system.

Identity Governance Leads

Permissions are the objects examined during access reviews, entitlement certifications, and least-privilege analysis. Governance teams focus on detecting over-entitlement and privilege creep, which are lifecycle concerns distinct from runtime enforcement.

Compliance Officers and Auditors

Because permissions define exactly what a principal may do, they are central to demonstrating least privilege and segregation of duties. Auditors need to trace how granted permissions map to actual access decisions, keeping in mind that a held permission and an enforced decision are not the same thing.

System Administrators

Administrators grant, revoke, and troubleshoot permissions day to day. Understanding that a permission expresses only a capability, while the PDP and PEP make and apply the actual decision, is essential when diagnosing why a request was allowed or denied.

Inside Permission

Target resource or object

The specific system entity a permission applies to, such as a file, API endpoint, database record, or application function. A permission is meaningless without a defined object of protection.

Operation or action

The specific action allowed on the target, such as read, write, delete, execute, or approve. Permissions bind an action to a resource rather than describing identity.

Effect (allow or deny)

Whether the permission grants or forbids the action. In most deployments the default is implicit deny, with explicit allow entries granting access; some models also support explicit deny that overrides allows.

Grant mechanism

How the permission reaches a principal. In RBAC permissions are typically bundled into roles assigned to principals; in ABAC or PBAC they are evaluated from attributes and policy conditions at runtime; in ReBAC they derive from relationships between principals and resources.

Conditions or constraints

Optional context that must hold for the permission to apply, such as time of day, network location, or resource attributes. These are more central to ABAC and PBAC models than to static RBAC assignments, depending on configuration.

Enforcement point relationship

Permissions are evaluated by a policy decision point (PDP) and enforced by a policy enforcement point (PEP) at runtime, distinct from the governance processes that assign or certify them.

Common questions

Answers to the questions practitioners most commonly ask about Permission.

Is a permission the same thing as a role?

No. A permission is a discrete grant that authorizes a specific action on a specific resource (for example, read a particular object), while a role in RBAC is a named collection of permissions assigned to principals. A role is the aggregation mechanism; the permission is the atomic unit of authorization it groups. Conflating the two obscures how access is actually evaluated, since in most RBAC deployments the effective access is the union of permissions granted through all of a principal's roles.

Does holding a permission mean a principal has been authenticated?

No. A permission relates to authorization, not authentication. Authentication verifies who a principal is; a permission determines what that already-identified and authenticated principal may do. In a typical access flow, identification and authentication occur first, and only then is the principal's set of permissions evaluated to make an authorization decision. A permission existing in a policy or directory says nothing about whether the requesting party has proven their identity.

How are permissions typically evaluated at runtime?

In many deployments, a policy enforcement point (PEP) intercepts a request and consults a policy decision point (PDP), which evaluates the applicable permissions, often drawing additional attributes from a policy information point (PIP), and returns a permit or deny. The specific mechanism depends on the access control model and product: RBAC evaluations may resolve role-to-permission mappings, while ABAC or PBAC evaluations may compute permissions from attributes and policy rules at request time. The exact separation of these components varies by vendor and architecture.

Should permissions be assigned directly to users or granted through roles or policies?

This depends on the access control model and governance requirements. In RBAC, permissions are typically granted through roles rather than assigned directly to individual users, which simplifies administration and access reviews. Direct assignments can create governance gaps because they are harder to certify and to include in segregation-of-duties analysis. In ABAC or PBAC deployments, permissions may instead be derived from policies evaluated against attributes rather than statically assigned at all. The right approach depends on scale, auditability needs, and the model in use.

How do permissions relate to identity governance activities like access reviews?

Permissions are the underlying grants that governance processes ultimately account for, though reviewers often examine them indirectly through the roles, entitlements, or groups that bundle them. During access certification, reviewers typically confirm that a principal's effective permissions remain appropriate, and segregation-of-duties controls check for conflicting permission combinations. Note that governance is a lifecycle concern separate from runtime enforcement: certifying a permission during a review does not enforce it, and revoking it during a review may not take effect until provisioning propagates the change.

What is the difference between defining a permission and enforcing it?

Defining a permission is an administrative or governance concern, establishing that a given action on a given resource is grantable and assigning or deriving it for principals. Enforcing it is a runtime concern handled by enforcement components such as a PEP and PDP that evaluate the applicable permission when a request occurs. Because these are separate, a defined or provisioned permission may not be enforced consistently across every access path unless each enforcement point evaluates the same authoritative policy or entitlement data. The degree of consistency depends on the deployment architecture.

Common misconceptions

A permission and a role are the same thing.

A permission is a discrete authorization to perform an action on a resource, while a role (in RBAC) is a named collection of permissions assigned to principals. Roles are one grant mechanism for permissions, not synonyms for them; ABAC, PBAC, and ReBAC grant permissions through other means.

Holding a permission means the user has been authenticated for that action.

Permissions concern authorization, which is what a principal may do, and are logically separate from authentication, which verifies who the principal is. A permission is evaluated only after identification and authentication have established the principal, and possessing a permission says nothing about how or whether identity was verified.

Once granted, a permission remains appropriate indefinitely.

Permission assignments require ongoing governance. Access reviews, certification, and segregation-of-duties checks (IGA concerns) exist because grants can become excessive or stale over time, independent of the runtime enforcement that evaluates permissions at request time.

Best practices

Apply least privilege by granting only the specific operations on the specific resources a principal needs, rather than broad or bundled grants that exceed the actual requirement.

Choose the access control model deliberately for the use case: RBAC for stable role structures, ABAC or PBAC where context-dependent conditions matter, and ReBAC where access follows relationships, rather than defaulting to one model universally.

Keep permission definitions granular so that operations (read, write, delete, approve) on each resource can be granted independently instead of collapsing distinct actions into a single coarse grant.

Subject permission assignments to periodic access reviews and certification, and enforce segregation-of-duties rules to detect and remove excessive or conflicting grants over time.

Separate the governance of permission assignment from runtime enforcement, ensuring the PDP evaluates and the PEP enforces permissions consistently at request time based on current policy.

Prefer implicit deny as the default posture and document the effect (allow or deny) and any conditions explicitly so that authorization decisions are auditable and predictable.