When access rules are scattered across application code, services can enforce inconsistent permissions and make changes difficult to audit. Separation of concerns assigns enforcement, decision-making, policy management, and contextual data to distinct responsibilities. section 4.5.5 section 4.6
A reference authorization architecture separates four roles:
- Policy Enforcement Point (PEP) intercepts requests and enforces the resulting decision. section 4.4
- Policy Decision Point (PDP) evaluates policies and returns an access decision. section 4.4
- Policy Administration Point (PAP) creates and manages policies. section 4.4
- Policy Information Point (PIP) supplies contextual attributes from identity, time, network, and other systems. section 4.4
Changing an access rule safely
When Carol updates access to ACMEProject, the policy can be reviewed, tested, deployed, and audited without changing application code. The same rule can then serve multiple services, while decisions remain traceable to policy and contextual data. section 4.5.5
Figure 4.2 Authorization reference architecture showing how access decisions are made. The Policy Enforcement Point (PEP) intercepts Alice’s request to ACMEProject and sends it to the Policy Decision Point (PDP). The PDP evaluates the request using policies from the Policy Administration Point (PAP), managed by Carol, and retrieves context from the Policy Information Point (PIP), which sources attributes from systems such as identity providers, time servers, and network telemetry. The PDP returns a decision, which the PEP enforces in real time.
Follow the request from Alice through the PEP and PDP, including policy retrieval from the PAP, context retrieval from the PIP, and real-time enforcement. section 4.4
