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 AuthZEN spec defines decision (boolean) plus an optional context object. EmpowerNow places constraints and obligations inside context — the spec's extension point — so generic PEPs that only read decision still get a valid response, while first-party PEPs enforce the full payload.
{
"decision": true,
"context": {
"ttl_ms": 3000,
"constraints": [
{ "type": "egress_allow", "hosts": ["*.example.com"] },
{ "type": "spend_budget", "limit_usd": 25, "period": "daily", "provider": "openai", "model": "gpt-4o-mini" },
{ "type": "pii_redaction", "patterns": ["ssn", "credit_card"] },
{ "type": "rate_limit", "max_requests": 100, "window_seconds": 60 }
],
"obligations": [
{ "type": "audit_log", "reason": "policy:finance_travel", "criticality": "required" },
{ "type": "notification", "channel": "security_alerts", "criticality": "advisory" },
{ "type": "run_workflow", "name": "receipt_emit", "criticality": "required" }
]
}
}
AuthZEN — the OpenID Foundation standard — uses transport‑friendly JSON designed for streaming and real‑time enforcement. EmpowerNow extends the standard with typed constraints (five models: scope, time, location, rate limit, generic), obligations (with criticality levels), and Escalate for practical runtime enforcement. Rollout is controlled by feature flags (PDP_CONSTRAINTS_MODE: disabled → shadow → full) so existing clients stay stable.
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.