SSOGEN / Learn / Policy Enforcement Point (PEP): What It Is and Where It Sits

SSOGEN

Policy Enforcement Point (PEP): What It Is and Where It Sits

A policy enforcement point applies a decision made elsewhere. Here it stands beside the PDP, PAP and PIP, with the four places it runs.

Request a trial

Four roles, four places to run the PEP, one way in.

A policy enforcement point sits between a person (or a program) and a resource. It asks whether the request may proceed and does what the answer says: it lets the request through, blocks it, or sends the person off to prove more.

The PEP does not write the rules, and in a clean design it does not evaluate them either. The work is split:

a policy administration point holds the rules;
a policy decision point evaluates them;
policy information points supply the facts.

The split keeps the one piece that touches traffic small.

For older web apps, the PEP lives in the web tier. An agent in the web server, or a proxy in front of it, demands sign-in and a second factor from an app that was never built for either.

The four roles, from the standards

Two primary sources define these roles, and they agree on the split.

Role	XACML 3.0 (OASIS, 22 January 2013)	NIST SP 800-207 (August 2020)
PEP, policy enforcement point	“The system entity that performs access control, by making decision requests and enforcing authorization decisions.”	The system “responsible for enabling, monitoring, and eventually terminating connections between a subject and an enterprise resource.”
PDP, policy decision point	“The system entity that evaluates applicable policy and renders an authorization decision.”	Split in two: the policy engine makes the decision to grant, deny or revoke access, and the policy administrator sets up or shuts down the path by commanding the PEP.
PAP, policy administration point	“The system entity that creates a policy or policy set.”	Not a named component; enterprise policy is an input to the policy engine.
PIP, policy information point	“The system entity that acts as a source of attribute values.”	Data sources such as device-posture and threat-intelligence feeds that the policy engine reads.

RFC 2904, the AAA authorization framework (August 2000), uses the same two words in its glossary. The PDP is “the point where policy decisions are made” and the PEP is “the point where the policy decisions are actually enforced.”

XACML did not invent the vocabulary; it put a standard on an older split.

NIST SP 800-207 adds a detail that is easy to miss. It says the PEP is a single logical component that “may be broken into two different components”:

Client side. Its example is an agent on a laptop.
Resource side. A gateway in front of the resource.
Single portal. It can also be one portal acting as gatekeeper.

“The PEP” can therefore be an agent, a gateway or both. It has no single product shape.

Where the PEP runs for web access

A PEP usually runs in one of four places. The table shows where each runs, what it sees, what it enforces, and a documented example.

PEP form	Where it runs	What it can see	What it enforces	Example (docs read 2026-10-12)
Web-server agent	Inside Apache or another web server, in the request path	Every HTTP request to the sites it protects, and the identity it just established	Redirects to sign-in, allows or refuses, and passes identity to the app	mod_auth_openidc is an Apache module that acts as an OpenID Connect relying party; claims reach the application in headers and environment variables, and it can protect content served by Apache or by back ends behind it
Reverse proxy	A separate host in front of one or many apps	The full HTTPS request and the person’s sign-in state	Redirects unauthenticated browsers to sign-in, then checks authorization before forwarding	Google Cloud Identity-Aware Proxy: a central authorization layer for HTTPS applications, which redirects a user who is not signed in and checks the user’s IAM role
API gateway	At the edge of an API	Headers, query parameters, a bearer token	Calls an authorizer, then allows or returns 401 or 403	Amazon API Gateway Lambda authorizer: the gateway calls the function, the function returns an IAM policy, the gateway evaluates it and denies or invokes the method
Service-mesh sidecar	Beside each service	Source, destination and the request context of one call	Queries a decision service for each call and permits or blocks it	Envoy with Open Policy Agent: Envoy sends the request context to an OPA sidecar and itself enforces the allow or deny that comes back

Envoy shows the split cleanly. The sidecar proxy is the PEP and OPA is the PDP. OPA’s own documentation says Envoy, not OPA, enforces the result.

The API gateway example also shows a PDP can be a small function the gateway calls.

Why enforcing at the web tier gives a legacy app SSO and MFA

Old applications such as Oracle E-Business Suite, PeopleSoft and JD Edwards predate SAML and OpenID Connect. Their login is a form and a password table, and teams are rarely allowed to rewrite it.

Every request still goes through a web server, though. A PEP there can do three things without touching the app’s code:

Require a signed-in person first. An unauthenticated request never reaches the app.
Ask for more when the policy says so. Step-up (a second factor) is a decision the PEP carries out by redirecting. The app never sees it.
Hand the app the identity it expects. The app reads a request header or environment variable, which is how it was built to get an identity from older single sign-on products.

This is also the PEP’s limit. It enforces only what it can see, and a web-tier PEP sees requests and who sent them. It does not see:

what a user does inside the app after the page loads;
a back-end job that talks to the database directly;
any path that goes around it.

Two rules follow:

One way in. The proxy and the agent have to be the only way in. Leave a second route open and your PEP has a bypass.
Fail closed. If the decision service is unreachable, set the PEP to fail closed. Otherwise it quietly becomes a pass-through.

How SSOGEN maps to these roles

SSOGEN fills each role for web applications and for AI agents.

PEP at the web tier. The Web Agent runs inside Apache or Oracle HTTP Server in front of the app. It sends people to sign in, passes identity to the app as headers, and strips any identity header a browser tries to send.

PEP as a proxy. The SSOGEN Gateway does the same job as a proxy, for apps that cannot host a module. It sends each person to SSOGEN, applies the app’s policy, and only then passes the request on.

Fail closed. If the gateway cannot reach its controller, protected routes are refused. The page on the identity-aware proxy covers that pattern in detail.

Decision in the SSOGEN server. SSOGEN makes one sign-in decision each time a person opens an app. It checks:

whether the person is assigned to the app;
whether the app is ready;
what the company’s access rules and the app’s policy say;
whether the session is strong enough.

If a fact is missing. The answer is no. If the sign-in is weaker than the policy needs, the person is sent to prove more (see how sign-in decisions work and adaptive authentication).

XACML roles. The SSOGEN server plays the PDP. The policies and rules an administrator edits play the PAP.

Per-call decisions for AI agents. The MCP Gateway is a checkpoint in front of MCP servers.

Checks for each tool call. It checks the agent and the person it acts for, and checks the tool is inside the granted scope. Then it allows the call, refuses it or holds it for the person’s approval.

PEP for single tool calls. The scopes it checks are the ones drafted in AI agent permissions.

The SSO gateway page shows how these gateway pieces fit together.

IdP vs SP covers the federation roles, a different pair from PEP and PDP. The identity provider proves who someone is. The PEP applies what they may do.

Questions people ask

What is the main goal of security policies?

To say in one place who may do what to which resource, and under what conditions, so everyone applies it the same way. A policy turns “we should be careful” into rules a person or system can follow and an auditor can check. A policy enforcement point is how a written access rule becomes an action.

What does policy enforcement mean?

It means carrying out an access decision at the moment of a request. Allow it, block it, or ask for more proof first. In XACML terms the policy enforcement point makes the decision request and enforces the answer. Evaluating the policy is a separate job, done by the policy decision point.

What is an access control policy?

A set of rules saying which subjects (people, services, agents) may perform which actions on which resources, often with conditions like device, location or sign-in strength. XACML calls a collection of such rules a policy set. A policy administration point creates it and a policy decision point evaluates it.

Can you give me an example of a security policy?

“Finance users may open the payroll application only after a second factor, and contractors may not open it at all.” A web-tier policy enforcement point applies that by redirecting an unauthenticated finance user to sign-in and asking for the second factor. It refuses a contractor before the request reaches the app.

Where to go next

Start with the SSO gateway overview, then read:

the Web Agent and the Gateway as enforcement points;
the MCP Gateway for AI agent tool calls, and AI agent permissions;
adaptive authentication, IdP vs SP and the identity-aware proxy.

Sources, all read 2026-10-12:

NIST, SP 800-207, Zero Trust Architecture, August 2020, section 3, logical components.
OASIS, eXtensible Access Control Markup Language (XACML) Version 3.0, OASIS Standard, 22 January 2013, section 1.1.1 glossary.
IETF, RFC 2904, AAA Authorization Framework, August 2000.
OpenID Connect module for Apache, mod_auth_openidc.
Google Cloud, Identity-Aware Proxy overview.
AWS, API Gateway Lambda authorizers.
Open Policy Agent, Envoy external authorization.