Policy Enforcement Point (PEP)

The most common implementation for protecting RESTful and GraphQL APIs. The PEP is deployed as a sidecar proxy (e.g., Envoy with ExtAuthz) or a gateway plugin that intercepts all incoming HTTP/HTTPS traffic.

• Intercepts: All API calls before they reach business logic.
• Enforces: Decisions based on user tokens (JWT), API keys, and requested resource paths.
• Example: A PEP in an API gateway checks if a user's role has GET permission for /api/v1/customers/{id} before routing the request.

Implemented within or in front of the database to enforce row-level and column-level security. This is crucial for semantic data governance where policies are based on data classification.

• Intercepts: SQL, SPARQL, or Cypher queries before execution.
• Enforces: Query rewriting or runtime filtering based on user attributes and data labels.
• Example: A PEP integrated with a graph database rewrites a user's query to automatically filter out nodes tagged as confidential unless the user has a clearance:high attribute.

Embedded within cloud storage services (e.g., AWS S3, Azure Blob Storage) or enterprise file systems to control access to unstructured data.

• Intercepts: GET, PUT, LIST operations on buckets, containers, or directories.
• Enforces: Policies based on resource tags, user groups, and IP ranges.
• Example: A PEP in an S3 bucket policy denies PutObject requests for objects tagged PII unless the request comes from a specific encrypted VPC endpoint.

Deployed in real-time data flow architectures (e.g., Apache Kafka, Flink) to govern data in motion. The PEP acts as a stream processor or Kafka interceptor.

• Intercepts: Messages being published to or consumed from topics.
• Enforces: Policies to redact, filter, or encrypt sensitive data fields within event payloads based on the consumer's context.
• Example: A PEP in a Kafka stream filters out credit_card fields from transaction events for all consumer applications except the payment processing service.

Implemented directly within the frontend application or backend service logic for fine-grained, context-aware UI/UX enforcement. This is often a client-side PEP working in tandem with a backend PEP.

• Intercepts: User actions like button clicks or requests to render specific UI components.
• Enforces: Dynamic UI rendering, enabling/disabling features based on user permissions and data context.
• Example: A PEP in a React component hides a "Delete Customer" button unless the user has the admin role and the customer record is not flagged as active_legal_hold.

Integrated into semantic data catalogs and knowledge graph interfaces to control the visibility and accessibility of metadata and data assets.

• Intercepts: Search queries and requests to view dataset schemas, lineage diagrams, or sample data.
• Enforces: Policy-driven filtering of search results and metadata details based on the user's domain and data classification entitlements.
• Example: A PEP in a data catalog prevents users in the marketing domain from discovering datasets tagged with HR:Compensation, even if their search terms match.

The Policy Decision Point (PDP) is the core reasoning engine in a policy-based access control system. It evaluates incoming access requests—containing attributes about the user, resource, action, and environment—against a set of predefined authorization policies. The PDP renders a definitive decision (e.g., Permit, Deny, Not Applicable) and may also generate obligations (e.g., 'must log this access') that the PEP must enforce.

• Key Function: Makes the authorization decision; the 'brain' of the system.
• Relationship to PEP: The PEP acts on the PDP's decision. They communicate via standard protocols like XACML.
• Example: A PDP evaluates if a user in the 'Analyst' role can 'READ' a 'Customer' resource classified as 'Confidential'.

The Policy Information Point (PIP) acts as the source of attribute data required by the Policy Decision Point (PDP) to evaluate a policy. It is a queryable interface to external data sources such as LDAP directories, databases, or environmental systems.

• Key Function: Retrieves and provides dynamic attribute values (e.g., user department, resource owner, current time).
• Relationship to PEP/PDP: The PDP queries the PIP to gather missing attributes not present in the original request from the PEP.
• Example: When a PDP needs to check if a user is in the 'Managers' group, it queries a PIP connected to the corporate Active Directory.

The Policy Administration Point (PAP) is the management interface where security administrators define, manage, store, and distribute authorization policies to the Policy Decision Point (PDP). It is the central console for the lifecycle of access control rules.

• Key Function: Creates, updates, and deploys the policy sets that the PDP evaluates.
• Relationship to PEP/PDP: The PAP pushes the active policy set to the PDP. Changes in the PAP directly affect future decisions.
• Example: An administrator uses a PAP's graphical interface to create a new rule: 'Deny all access to PII data from IP addresses outside the corporate VPN.'

Attribute-Based Access Control (ABAC) is a dynamic authorization model where access decisions are based on the evaluation of attributes associated with the user, resource, action, and environment. It enables fine-grained, context-aware policies (e.g., 'A project manager can edit a document if the document's project attribute matches the user's project attribute and the time is within business hours').

• Key Concept: Policies are expressed as rules over attributes, not static user-role assignments.
• Relationship to PEP: A PEP in an ABAC system intercepts requests and must collect a rich set of attributes to send to the PDP for evaluation.
• Standard: The eXtensible Access Control Markup Language (XACML) is a policy language and architectural model for implementing ABAC.