Authorization Fundamentals
PAP authors policy. PDP evaluates decisions using PIPs
PEPs enforce constraints and obligations at the right boundary (IdP at issuance; Gateway/services at runtime).
Modern Attribute‑Based Access Control (ABAC) using OpenID AuthZEN. PAP authors versioned policy, PDP evaluates decisions with PIPs, and PEPs enforce constraints (sync) and obligations (async) at the correct boundary (IdP at issuance; Gateway/Service at runtime). Note: constraints and obligations shown here are EmpowerNow extensions to the AuthZEN decision and are not part of the current AuthZEN specification.
PDP • PEP • PIP • PAP
- PAP: tooling/versioning for policies; change‑controlled.
- PIPs: trusted attribute/context providers (e.g., membership, search, geo).
- PDP: returns an AuthZEN decision. EmpowerNow includes optional extension fields for constraints (sync) and obligations (async).
- PEPs: enforce at the right layer — IdP for issuance obligations; Gateway/Service for runtime constraints.
About the OpenID AuthZEN Working Group
The OpenID AuthZEN Working Group defines interoperable mechanisms, protocols, and formats to communicate authorization information between components (e.g., PDP, PEP, PIP, PAP). EmpowerNow builds on AuthZEN decisions and adds product‑level extension fields like constraints and obligations for practical enforcement.
ABAC in AuthZEN terms
Subject
Who/what performs an action. Examples: role, department, clearance, certifications.
Action
Operation being requested (read, write, transfer). Rich attributes like amount or channel.
Resource
The object affected (document, account, case). Attributes like classification or owner.
Context
Time, device, location, risk score. Used for run‑time checks (EmpowerNow extensions like constraints/obligations).
AuthZEN decision example
A PDP evaluates attributes and returns a decision. The example below shows EmpowerNow extension fields — constraints (to be enforced synchronously by the PEP) and obligations (post‑actions) — which are not part of the current AuthZEN specification.
{
"decision": "Permit",
"ttl": 3000,
"constraints": {
"egress_allow": ["*.example.com"],
"models_allow": ["gpt-4o-mini"],
"spend_budget_usd": 25
},
"obligations": [
{ "type": "audit_log", "reason": "policy:finance_travel" },
{ "type": "run_workflow", "name": "receipt_emit" }
]
}
Compared to legacy XACML, AuthZEN uses transport‑friendly JSON designed for streaming and real‑time enforcement. EmpowerNow adds extension fields such as constraints and obligations for practical runtime and issuance enforcement.
Migrating from XACML to AuthZEN
- Policy: keep ABAC model; translate rules to AuthZEN‑compatible PAP syntax or authoring tools.
- Requests: map XACML categories to subject/action/resource/context JSON objects.
- Decisions: replace XACML Result with an AuthZEN decision; EmpowerNow can include extension fields for constraints and obligations (and TTL).
- PEPs: enforce constraints at runtime (gateways/services) and perform obligations (issuance/audit).
Where we implement this
- IdP (PEP): RFC 8693 Token Exchange with consent obligations; DPoP; pairwise.
- Gateway (PEP): runtime guardrails (params, egress, model caps, budgets).
- PDP: Draft‑04 AuthZEN endpoints; PIPs for membership/search; EmpowerNow extensions for constraints/obligations.
- PAP: policy authoring + versioning; deployment to PDP.