Category: Authorization Concepts

Policy Decision Point

Also known as: PDP, policy engine, rules engine, authorization engine

Simply put

A Policy Decision Point (PDP) is the component that decides whether a given access request should be allowed or denied. It does this by checking the request against the applicable authorization policies and any relevant contextual data, then returns a decision. The PDP focuses on making the decision, not on collecting the request or enforcing the outcome.

Formal definition

In an authorization architecture, the PDP is the component that computes access decisions by evaluating applicable policies (and, in some models, metapolicies) against an incoming authorization query. It functions as a policy or rules engine that receives a decision request, typically forwarded from a Policy Enforcement Point (PEP), along with contextual attributes sourced from Policy Information Points (PIPs), and returns a permit/deny (and sometimes obligation-bearing) result. The PDP performs authorization evaluation only; it does not typically intercept or enforce access itself, which is the PEP's responsibility, and it is distinct from IGA lifecycle functions such as provisioning or access certification. It can support various policy models (for example RBAC, ABAC, or PBAC) depending on the policy language and engine, and separating the PDP from application code is a common design pattern to centralize and scale authorization logic. Specific query formats, policy languages, and integration mechanisms vary by vendor and deployment.

Why it matters

The Policy Decision Point is where authorization actually happens, the moment an access request is resolved into a permit or deny. Because this decision governs what a principal may do (as distinct from authentication, which establishes who the principal is), the correctness and consistency of the PDP directly shapes the security posture of every protected resource behind it. When authorization logic is scattered across application code, decisions drift out of sync, become difficult to audit, and are prone to inconsistent enforcement. Centralizing decision-making in a dedicated PDP is a common design pattern precisely to make authorization logic consistent, testable, and reviewable in one place.

Who it's relevant to

Security architects

Architects deciding how to structure authorization use the PDP as the anchor point for separating decision logic from enforcement. Understanding the PDP/PEP/PIP split lets them design systems where authorization is centralized and consistent rather than duplicated across services, and choose an engine whose supported policy model (RBAC, ABAC, PBAC, and so on) fits their requirements.

IAM and platform engineers

Engineers who integrate authorization into applications rely on the PDP to answer decision requests forwarded from PEPs. Running the PDP as a separate service can decouple authorization from application code, which affects how they deploy, scale, and version policies. They also need to be clear that the PDP decides but does not enforce, enforcement remains at the PEP.

Compliance and audit teams

Because the PDP is where access decisions are computed against defined policies, it is a natural focal point for demonstrating how authorization rules are applied. Note, however, that the PDP addresses runtime access decisions and is distinct from IGA lifecycle functions such as provisioning and access certification, which are governed separately.

Inside PDP

Policy Evaluation Engine

The core logic that receives an authorization request and evaluates it against configured policies to render an access decision, typically permit or deny. The PDP is a runtime enforcement concern, distinct from identity governance functions such as provisioning or access certification.

Decision Request/Response Interface

The interface through which a Policy Enforcement Point (PEP) submits an authorization query and receives the PDP's decision. The PDP decides; the PEP enforces. This separation is central to policy-based access control architectures.

Policy Retrieval

The mechanism by which the PDP obtains the applicable policies to evaluate. Depending on configuration, policies may be loaded from a policy repository or administration point, and the PDP applies them to the incoming request context.

Attribute Consumption via PIP

The PDP typically relies on a Policy Information Point (PIP) to supply additional attributes (about the subject, resource, action, or environment) needed to evaluate a policy. In ABAC and PBAC models, these attributes drive the decision.

Decision Context

The set of inputs, commonly subject, resource, action, and environmental attributes, that the PDP evaluates. The exact context model varies by standard, profile, and vendor deployment.

Common questions

Answers to the questions practitioners most commonly ask about PDP.

Does the PDP enforce access decisions?

No. The PDP evaluates policy and returns a decision (such as permit or deny), but it does not enforce that decision. Enforcement is the responsibility of the Policy Enforcement Point (PEP), which intercepts the access request, calls the PDP, and then acts on the returned decision by allowing or blocking the request. Conflating the two blurs the separation between decision-making and runtime enforcement that this architecture is designed to maintain.

Does the PDP authenticate the user?

No. The PDP is an authorization component; it determines what a principal may do, not who the principal is. Authentication is handled separately, typically before the request reaches the PEP, and the resulting identity and attributes are passed into the authorization flow. The PDP consumes those already-established identity attributes and other contextual inputs to evaluate policy, but it does not verify the principal's identity itself.

Where does the PDP get the attributes it needs to evaluate a policy?

In most deployments, the PDP retrieves additional attributes from one or more Policy Information Points (PIPs), which act as sources for subject, resource, action, and environmental attributes. Some attributes may also arrive directly in the request from the PEP, depending on configuration. The exact mix of PEP-supplied versus PIP-retrieved attributes varies by deployment and affects both latency and the freshness of the data used in a decision.

How is the PDP typically deployed relative to the PEP?

Deployment patterns vary. In some architectures the PDP is a centralized service that multiple PEPs call over the network, which simplifies policy consistency but adds a network dependency to each decision. In others the PDP is embedded or co-located with the PEP (for example as a sidecar or library) to reduce latency. The choice depends on requirements for latency, availability, and centralized policy management, and each pattern involves trade-offs.

What can be done to reduce PDP latency for high-volume authorization requests?

Common approaches include caching decisions or attributes, co-locating or embedding the PDP near the PEP, and minimizing external PIP lookups on the hot path. Any caching strategy involves a trade-off between performance and decision freshness, since cached decisions may not reflect recent policy or attribute changes. Appropriate cache lifetimes and invalidation depend on the deployment's tolerance for stale authorization outcomes.

How do policy changes propagate to the PDP?

This depends on the implementation and how policies are administered. In many systems a policy administration component distributes updated policies to the PDP, after which subsequent evaluations use the new rules. The propagation mechanism and timing vary by vendor and deployment, so it is important to understand how quickly changes take effect and whether in-flight or cached decisions continue to reflect prior policy until refreshed.

Common misconceptions

The PDP authenticates users before granting access.

The PDP handles authorization, not authentication. It determines what an already-identified and authenticated principal may do; verifying who the principal is occurs earlier and separately from the PDP's decision-making.

The PDP enforces access by blocking or allowing the actual request.

The PDP renders a decision but does not enforce it. Enforcement is the responsibility of the Policy Enforcement Point (PEP), which acts on the decision the PDP returns. Blurring these roles misrepresents the architecture.

A PDP is tied to a single access control model such as RBAC.

A PDP evaluates whatever policies it is configured with, and can support RBAC, ABAC, PBAC, or ReBAC depending on the deployment. No single model is universally applied or inherently superior; the model depends on how policies and attribute sources are configured.

Best practices

Keep the PDP's decision-making cleanly separated from the PEP's enforcement, so that policy logic can evolve independently of enforcement points.

Ensure the PDP has reliable access to the attributes it needs, typically by integrating a well-defined PIP, since ABAC and PBAC decisions depend on accurate and current attribute data.

Manage authorization policies through a controlled administration and repository process, keeping runtime PDP evaluation distinct from identity governance activities like access reviews and certification.

Validate that the request context supplied to the PDP is complete and trustworthy, since the quality of subject, resource, action, and environmental attributes directly affects decision correctness.

Document the access control model or models the PDP is configured to evaluate, and align policy authoring accordingly rather than assuming a single default model.

Account for vendor and profile variation in PDP behavior, and test decision outcomes against your specific deployment rather than relying on absolute assumptions about how policies evaluate.