A Policy Enforcement Point (PEP) protects an enterprise’s data by enforcing access control as a vital component of the XACML architecture. XACML is an OASIS Open standard and stands for “eXtensible Access Control Markup Language”. It is an XML-based markup language designed specifically for Attribute-Based Access Control (ABAC). The standard defines a declarative fine-grained, attribute-based access control policy language, an architecture, and a processing model describing how to evaluate access requests according to the rules defined in policies.
A XACML architecture is made up of 5 major component types: Policy Administration Points (PAPs), Policy Decision Points (PDPs), Policy Information Points (PIPs), Policy Retrieval Points (PRPs), and Policy Enforcement Points (PEPs).
A PEP is responsible for receiving authorization requests from the PDP for evaluation. The PDP and PEP work together to interpret policies to control the behavior of the network devices in order to satisfy both the users and administrators of network resources. However, a PEP is only responsible for requesting and evaluating an authorization decision and doesn’t require any authorization logic. Unlike PDPs, PEPs cannot be centralized in a SaaS application. This is because authorization and access control are required to be implemented throughout an application and its access points. PEPs can be applied to APIs, microservices, or any point in the application where access control is needed. Making PEPs pervasive in an application ensures that authorization is verified often and independently at multiple points.
Let’s walk through how a PEP works in the XACML architecture. First, a user takes action on a resource by making a request to the gate which protects that resource, which is a Policy Enforcement Point (PEP). The PEP will then form a request based on the user’s attributes, the resource they wish to access, the action they are attempting to take on that resource, and other relevant information pertaining to the request. The PEP sends this request to the PDP, which evaluates the request and the policy that applies to the request and decides whether access should be granted. That answer is then sent back to the PEP, which can then allow or deny access to the requester.
If you’d like to read more about the other components of the XACML architecture, read our previous blogs on PDP and PAP.