Enforcement Strategies: When PEPs are not enough

At the heart of modern authorization is the PEP/PDP architecture. But what if the target application doesn’t support PEP integration?

David Brossard   ·   Wednesday, October 15th, 2025   ·   Reading Time: 4 minutes

At the heart of modern authorization is the Policy Enforcement Point/Policy Decision Point (PEP/PDP) architecture, which is often considered the “gold standard” for fine-grained, real-time access control.

But what if the target application doesn’t support PEP integration?

In those cases, provisioning or token-based strategies can provide viable alternatives — extending the power of centralized policy without requiring intrusive changes to applications.

In this article, we’ll explore each of these different enforcement strategies: the “proper” PEP/PDP method, the realities of policy and entitlement provisioning, and token-based techniques that enrich access decisions at the point of authentication.

The “proper” approach: PEP/PDP

The best way to achieve fine-grained runtime authorization is through the “infamous” NIST ABAC PEP/PDP architecture: the application that needs to be protected is installed behind a Policy Enforcement Point (PEP) or uses a PEP within its own application logic. This architecture is defined both in NIST SP 800-162 and NIST SP 800-207 on Zero Trust.

In this approach, applications are fronted with a PEP which intercepts inbound and optionally outbound traffic. The PEP is capable of understanding the end-user’s identity and crafting an authorization request from the business flow e.g. “Can Alice view record #123?”. An example of a PEP is an API gateway.

The provisioning approach

But what if an application can’t be protected by a PEP? If the target application has robust built-in authorization capabilities, we can try to provision configurations directly to it — assuming the application provides a way to do so. This approach aligns with the methods used by Identity Governance and Administration (IGA) solutions like SailPoint.

For this approach to work, we need:

1. An application with a rich internal authorization model,
2. A means to convert Axiomatics’ authorization policies into the format expected by the application, and
3. A means to provision the configuration to the application’s internals.

There are two main ways to approach the provisioning:

Entitlement Provisioning

Entitlement provisioning is used when a target application supports a rich, identity-centric internal authorization model – a prime example being Salesforce. In such systems, authorization is driven through user-specific metadata, such as licenses, profiles, roles, permission sets, and permission set groups.

The key takeaway is that some applications provide robust native authorization models we can integrate with directly. In these cases, we can use Axiomatics’ Contextual Authorization Query (CAQ) API to ask contextual questions like “Which permission sets can I assign to Alice?” Based on the response, we determine when and how to call the target application’s admin APIs to provision the appropriate entitlements.

However, it’s important to note that entitlements are typically identity-centric, and translating ALFA policies from Axiomatics into specific entitlements can result in some loss of granularity or contextual nuance. Additionally, entitlement provisioning is not true runtime authorization because it happens at predefined moments, such as during authentication, session refresh, or other specific events.

Policy Provisioning

Most provisioning use cases involve applications that are identity-centric, role-based, or entitlement-driven. However, some target applications instead use an authorization policy format.

For example, Kubernetes uses ABAC policies to enable fine-grained access control use cases. Microsoft Entra supports conditional access policies, while other products may include a policy decision point (PDP) using other languages like Open Policy Agent’s Rego.

Older examples include Windows Server 2012 which introduced SDDL (Security Descriptor Definition Language), a text-based format for defining security descriptors for objects like files, services, and registry keys, enabling fine-grained access control on server files and folders.

In those cases, we should consider translating from Axiomatics policies (ALFA) into the target language. Depending on the capabilities of that language, it may be possible to express the entire scope of what the ALFA Policy intends. Policy provisioning allows Axiomatics to function not only as an enterprise policy management solution but also as a policy orchestration platform — capable of managing and tracking policies across multiple languages.

The token-based approach

If provisioning is out of the question whether for lack of an administrative API to provision to or for lack of a rich authorization model, another tangible approach is a token-based angle. If the target application has integrated into an authentication and federation solution such as an OpenID-based solution or SAML-solution, then it uses and understands tokens (access tokens, identity tokens, SAML assertions…).

As a result, we can design a system whereby the Identity Provider (e.g. Okta) can be configured to call a third-party service during the token issuance process. One such service can be a PDP e.g. Axiomatics’ Access Decision Service. The PDP can process its policies and support the generating a set of claims that are returned to the IdP and injected into the token. In Okta, we can use a custom action in a post-login flow.

Using a token-based approach enriches the access token and allows the application to extract the newly inserted claims and use them as it sees fit. Because the application is already configured to use tokens, this approach is unintrusive and helps support Zero Standing Privileges by making sure the token doesn’t contain more than what is needed.

The future: AuthZEN

In addition to the approaches mentioned above, we’d like to acknowledge the work being developed in the OpenID Foundation under the helm of the AuthZEN Working Group.

The AuthZEN Working Group is working to create a standardized framework for applications to communicate with policy-based authorization systems. By defining common protocols and formats for fine-grained authorization decisions, AuthZEN enables applications to delegate enforcement to trusted third-party services like Axiomatics Orchestrated Authorization. This approach enables consistent fine-grained access, dynamic separation of duty, and many more access control use cases across a range of applications. The Axiomatics team actively contributes to the working group to help shape the future of standardized, scalable authorization enforcement.

What this means for your organization

At Axiomatics, our mission is to deliver fine-grained, runtime authorization wherever possible — eliminating standing privileges and birth rights in the process. While we advocate for the PEP/PDP model as the most secure and dynamic approach, we recognize the need for flexibility.

Whether through provisioning, token-based methods, or PEP/PDP, our goal remains the same: enabling intelligent, context-aware access decisions across your entire application landscape.

Want to learn more about enforcement strategies? We cover this and other popular topics around authorization in our latest version of The State of Authorization: Playbook Edition.