Day 08: Policy Decision Point (PDP) - Concepts | EmpowerNow Developer Academy

📋Learning Objectives

Understand what a PDP does and why it matters
Learn the AuthZEN 1.1 specification basics
Understand policy structure: applications, resources, actions
Master YAML policy syntax and JSON policy format (IGA)
Know the four IGA policy categories: guardrails, SoD, birthright, temporal
Understand pdp_application routing and rich decision context
Understand the 5-level inheritance hierarchy

🎯What is a Policy Decision Point?

Imagine you're a bouncer at a VIP club. Someone shows you their ID (authentication). But knowing they're "John Smith" doesn't tell you if they're on the guest list, if their membership is active, or if they're allowed in the VIP section. You need a policy to make that decision. The PDP is that bouncer—for every API call, database query, and button click in your application.

The PDP is the brain of the authorization system. It answers the question:

"Can Subject perform Action on Resource?"

Key Concepts

Subject: Who is making the request (user, service, role)
Action: What operation they want to perform (read, write, delete)
Resource: What they want to access (document, API endpoint, feature)
Context: Additional attributes (time, location, device)

PDP Authorization Flow

flowchart TB subgraph Request["📥 Authorization Request"] S["👤 Subject
(User)"] A["⚡ Action
(Read)"] R["📄 Resource
(Document)"] end S --> PDP A --> PDP R --> PDP PDP["🧠 PDP
Policy Evaluation"] PDP --> D{Decision} D -->|"✅"| PERMIT["✅ PERMIT
Access Granted"] D -->|"❌"| DENY["❌ DENY
Access Denied"] style PDP fill:#7c3aed,color:#fff style PERMIT fill:#059669,color:#fff style DENY fill:#e11d48,color:#fff

📜AuthZEN 1.1 Specification

Just like OAuth standardized authentication APIs, AuthZEN standardizes authorization APIs. Instead of every vendor inventing their own way to ask "is this allowed?", AuthZEN defines a common language. This means you can swap PDPs without rewriting your application—and your skills transfer across organizations.

EmpowerNow PDP implements the AuthZEN 1.1 specification, a standard for authorization APIs:

Standard Endpoints

Endpoint	Method	Purpose
`/access/v1/evaluation`	POST	Single authorization decision
`/access/v1/evaluations`	POST	Batch authorization decisions
`/access/v1/search`	POST	Search for allowed resources/actions

Standard Request Format

{
  "subject": {
    "type": "user",
    "id": "user-uuid-123",
    "properties": {
      "department": "engineering"
    }
  },
  "action": {
    "name": "read"
  },
  "resource": {
    "type": "document",
    "id": "doc-456",
    "properties": {
      "classification": "confidential"
    }
  },
  "context": {
    "time": "2024-01-15T10:30:00Z",
    "ip_address": "192.168.1.100"
  }
}

Standard Response Format

{
  "decision": true,           // or false
  "context": {
    "reason_admin": {
      "explanation": "User has 'reader' role on document"
    }
  }
}

🧪 Try It: Make an Authorization Request Interactive

Copy curl and run in your terminal to ask the PDP: "Can user Alice read the products catalog?" This is a real AuthZEN evaluation request!

✅ What to Expect

You should see "decision": true because reading products is allowed for all users in the it-shop application.

🚫 Try It: A Denied Request Interactive

Copy curl and run in your terminal to try something that should be denied—deleting products without admin role:

✅ What to Expect

You should see "decision": false because only users with the product-admin role can delete products.

🚀The Authorization Request Journey

Let's follow an authorization request from start to finish. When your API receives a request, what happens behind the scenes? Understanding this flow will help you debug authorization failures and optimize performance.

Complete Authorization Flow

sequenceDiagram participant User as 👤 User participant API as 🌐 API Gateway participant PDP as 🧠 PDP participant Cache as ⚡ Redis Cache participant Policies as 📁 Policy Store participant PIPs as 🔌 PIPs User->>API: GET /products/123 API->>API: Extract JWT claims Note over API,PDP: Build AuthZEN Request API->>PDP: POST /access/v1/evaluation PDP->>Cache: Check decision cache alt Cache Hit Cache-->>PDP: Cached decision else Cache Miss PDP->>Policies: Load applicable policies Policies-->>PDP: Policy rules PDP->>PIPs: Fetch additional attributes PIPs-->>PDP: User roles, resource metadata PDP->>PDP: Evaluate rules PDP->>Cache: Store decision end PDP-->>API: {"decision": true/false} alt Decision = true API-->>User: 200 OK + Data else Decision = false API-->>User: 403 Forbidden end

Step-by-Step Breakdown

Request Arrives: User makes an API request with their JWT access token
Extract Context: API extracts user ID, roles, and request details from the JWT and request
Build AuthZEN Request: API constructs the subject/action/resource/context JSON
Cache Check: PDP checks if this exact decision was recently made
Policy Loading: On cache miss, PDP loads policies for the application and resource type
Attribute Enrichment: Policy Information Points (PIPs) fetch additional data if needed
Rule Evaluation: PDP evaluates rules in order, applying inheritance
Decision & Caching: Result is returned and cached for future requests
API Response: API enforces the decision—either returning data or 403

⚡ Performance Note

The cache check happens first because most authorization decisions are repetitive. A user accessing the same resource type multiple times will hit the cache after the first request, keeping latency under 1ms.

📁Policy Structure

Policies aren't thrown into a single giant file—they're organized like a well-structured codebase. Each application gets its own namespace, each resource type gets its own policy file, and inheritance keeps things DRY. Understanding this structure is essential before you start writing policies.

Policies are organized in a hierarchical structure:

Policy File Structure

flowchart TB subgraph Policies["📁 policies/"] subgraph Apps["📁 applications/"] subgraph ITShop["📁 it-shop/"] ITShopPolicy["📄 principal-policy.json
Application principal policy"] end subgraph IGA["📁 identity-governance/"] PrincipalPolicy["📄 principal-policy.json"] subgraph GuardrailsDir["📁 guardrails/"] GR["📄 contractor-restrictions.json"] end subgraph SoDDir["📁 sod/"] SOD1["📄 payment-vendor-sod.json"] SOD2["📄 hr-payroll-sod.json"] end subgraph BirthrightDir["📁 birthright/"] BR["📄 engineering-birthright.json"] end subgraph TemporalDir["📁 temporal/"] TEMP["📄 contractor-expiration.json"] end end subgraph IdP["📁 idp/"] IdPPolicy["📄 principal-policy.json"] end end subgraph Global["📁 global/"] BaseSec["📄 base-security-policy.json
Global security baseline"] GlobalSec["📄 global-security-baseline.json"] Recert["📄 recertification-auto-policies.json"] end end style ITShopPolicy fill:#f59e0b,color:#000 style BaseSec fill:#7c3aed,color:#fff style PrincipalPolicy fill:#10b981,color:#fff style IdPPolicy fill:#3b82f6,color:#fff

🆕 Identity Governance Application

The identity-governance PDP application organizes IGA policies into four categories: guardrails, SoD, birthright, and temporal. Each category has its own subdirectory and evaluates different resource types. Policies use JSON format with structured denyIf/allowIf conditions.

Application Scoping via `pdp_application`

Each application has its own policy namespace. The PDP determines which policy set to use via the resource.properties.pdp_application field:

{
  "resource": {
    "type": "group",
    "id": "IT-Admins",
    "properties": {
      "pdp_application": "identity-governance"
    }
  }
}

PDP extracts pdp_application from resource.properties
Resolves the application context from the registry
Loads policies from the application's configured directories
Applies the inheritance hierarchy and returns the decision

⚠️ pdp_application Location

The pdp_application field lives inside resource.properties, not in context. Missing values default to "global". Invalid format returns HTTP 400; unknown application IDs return HTTP 422.

Example Application IDs

Application ID	Purpose	Policy Format
`it-shop`	Shopping features (cart, products, orders)	JSON
`identity-governance`	IGA: guardrails, SoD, birthright, temporal	JSON
`experience`	Experience app UI access	YAML
`entraid-admin`	EntraID administration	YAML

🛡️IGA Policy Categories

Identity Governance takes PDP beyond "can user view this page?" into provisioning governance: "Can this contractor join an admin group? Does this role assignment create a fraud risk? What systems should a new hire get access to?" These are the four pillars of IGA policy enforcement.

🚧 Guardrails (GR-xxx)

"Can this provisioning action proceed?"

Resource types: iga.guardrail, group

Example: Contractors blocked from *-Admins groups

⚖️ Separation of Duties (SOD-xxx)

"Does this role create a toxic combination?"

Resource types: iga.sod, role

Example: Payment approver + vendor manager = fraud risk

🎁 Birthright Provisioning (BR-xxx)

"What should a new hire automatically get?"

Resource types: iga.birthright, target_system

Example: Engineering FTE → EntraID + AD + OpenLDAP

⏱️ Temporal Constraints (TEMP-xxx)

"Is this access still valid in time?"

Resource types: iga.temporal

Example: Contractor expired, 4-hour emergency access

IGA Policy Evaluation Flow

sequenceDiagram participant Agent as 🤖 AI Agent / Workflow participant PDP as 🧠 PDP (identity-governance) participant MemberPIP as 👥 Membership PIP Agent->>PDP: CheckGuardrail (contractor → IT-Admins) PDP->>MemberPIP: Fetch employee_type MemberPIP-->>PDP: Contractor PDP-->>Agent: DENY + GR-001 (remediation, reason) Agent->>PDP: CheckSoD (payment_approver → vendor_manager) PDP-->>Agent: DENY + SOD-001 (toxic combination) Agent->>PDP: DiscoverBirthright (FTE, Engineering) PDP-->>Agent: PERMIT (av_entraid, av_ad, av_openldap)

IGA Resource Types

Resource Type	Category	Actions
`iga.guardrail`	Guardrails	`evaluate`
`iga.sod`	Separation of Duties	`evaluate`
`iga.birthright`	Birthright Provisioning	`evaluate`
`iga.temporal`	Temporal Constraints	`evaluate`
`group`	Guardrails target	`add_to_group`
`role`	SoD target	`acquire_role`
`target_system`	Birthright target	`birthright_provision`

📝YAML Policy Syntax

YAML is human-readable, which makes policies easier to review and audit than code. But with great readability comes great responsibility—indentation matters, and one typo can deny access to your entire user base. Let's learn the syntax that keeps your applications secure.

Policies are written in YAML with a specific schema:

Basic Policy Structure

# products.yaml - Policy for products resource
name: products
description: Access control for product catalog

rules:
  - id: allow-read-all
    description: Anyone can read products
    effect: permit
    subjects:
      - type: any
    actions:
      - read
      - list
    
  - id: allow-admin-write
    description: Admins can modify products
    effect: permit
    subjects:
      - type: role
        id: product-admin
    actions:
      - create
      - update
      - delete
    
  - id: deny-default
    description: Deny all other access
    effect: deny
    subjects:
      - type: any
    actions:
      - any

Conditions

rules:
  - id: allow-own-orders
    description: Users can only view their own orders
    effect: permit
    subjects:
      - type: user
    actions:
      - read
    conditions:
      - attribute: resource.owner_id
        operator: equals
        value: subject.id

Time-Based Conditions

rules:
  - id: business-hours-only
    description: Access only during business hours
    effect: permit
    conditions:
      - attribute: context.time
        operator: time_between
        value:
          start: "09:00"
          end: "17:00"
          timezone: "America/New_York"

🔄JSON Policy Format (IGA Policies)

While standard resource policies use YAML, the IGA policies use a JSON-based format with structured conditions. This format makes policies machine-readable for agent workflows while staying auditor-friendly. The key difference: instead of listing subjects and actions, JSON policies use denyIf / allowIf blocks with condition arrays.

YAML vs JSON: Side by Side

YAML (Traditional — it-shop)

# products.yaml
rules:
  - id: allow-read-all
    effect: permit
    subjects:
      - type: any
    actions:
      - read

JSON (IGA — identity-governance)

{
  "id": "GR-001-contractor-no-admin",
  "effect": "DENY",
  "denyIf": {
    "operator": "AND",
    "conditions": [
      {"scope": "subject",
       "attribute": "properties.employee_type",
       "operator": "equals",
       "value": "Contractor"},
      {"scope": "resource",
       "attribute": "properties.name",
       "operator": "matches",
       "value": ".*-Admins?$"}
    ]
  }
}

JSON Condition Structure

Each condition in a denyIf or allowIf block has four fields:

Field	Purpose	Examples
`scope`	Where to look for the attribute	`subject`, `resource`, `context`
`attribute`	Dotted path to the value	`properties.employee_type`, `id`
`operator`	Comparison to perform	`equals`, `in`, `matches`, `contains_any`, `after_date`
`value`	Expected value or pattern	`"Contractor"`, `["admin", "editor"]`, `".*-Admins?$"`

Complete IGA Policy Example (GR-001)

{
  "id": "GR-001-contractor-no-admin-groups",
  "effect": "DENY",
  "denyIf": {
    "operator": "AND",
    "conditions": [
      {"scope": "subject", "attribute": "properties.employee_type",
       "operator": "equals", "value": "Contractor"},
      {"scope": "resource", "attribute": "properties.name",
       "operator": "matches", "value": ".*-Admins?$"}
    ]
  },
  // Rich context returned with the DENY decision
  "on_deny": {
    "context": {
      "guardrail_id": "GR-001",
      "reason_user": {"en": "Contractors cannot be added to admin groups"},
      "reason_admin": {"en": "GR-001: Contractor attempted to join admin group"},
      "remediation": "Remove admin group request or convert contractor to FTE"
    }
  }
}

💡 on_deny vs on_permit

on_deny.context is returned when the policy blocks access — it carries the reason, remediation steps, and guardrail/SoD IDs for auditing.

on_permit.context is returned when access is allowed — for birthright policies it carries what to provision (groups, attributes, licenses).

🏗️5-Level Inheritance Hierarchy

Writing the same "deny all by default" rule in 50 different files is madness. The 5-level inheritance hierarchy lets you define policies at the right level of granularity—from global defaults that protect everything, down to specific rules for individual documents. It's like CSS specificity, but for security.

Policies inherit from multiple levels, allowing for flexible and DRY configurations:

5-Level Policy Inheritance

flowchart TB L1["🌍 Level 1: Global Default
All applications"] L2["🏢 Level 2: Application Default
Single app scope"] L3["📦 Level 3: Resource Type
Type of resource"] L4["⚡ Level 4: Action
Specific action"] L5["🎯 Level 5: Instance
Specific resource"] L1 --> L2 --> L3 --> L4 --> L5 style L1 fill:#7c3aed,color:#fff style L2 fill:#3b82f6,color:#fff style L3 fill:#0891b2,color:#fff style L4 fill:#059669,color:#fff style L5 fill:#f59e0b,color:#000

Level	Scope	Example
1. Global	All applications	Deny access to blocked users
2. Application	Single app	IT Shop requires authentication
3. Resource Type	Type of resource	Documents require classification
4. Action	Specific action	Delete requires approval
5. Instance	Specific resource	This document requires manager role

Inheritance Example

// Level 2: Application default (principal-policy.json)
{
  "schema_version": "2.0",
  "application": "it-shop",
  "rules": [...]  // Application-scoped rules
}

# Level 3: Resource type (scoped via resource.type in rules)
name: products
inherit: true  # Inherit from application level
rules:
  - id: public-read
    effect: permit
    actions: [read]
    subjects:
      - type: any

💡 Best Practice

Start with restrictive global defaults (deny), then open up access at lower levels. This follows the principle of least privilege.

🔬Hands-on Labs

Theory is great, but nothing beats looking at real policies and making real authorization requests. These labs will give you hands-on experience with the PDP that you'll use tomorrow when writing your own policies.

LAB 1 Explore the Policy Directory ⏱️ 5 minutes

Let's explore the actual policy files that power the EmpowerNow platform.

1

Navigate to the policy directory: (replace <YourRepoRoot> with your project root, e.g. EmpowerNow)

# Windows (PowerShell)
cd <YourRepoRoot>\ServiceConfigs\Deployment\config\pdp\policies

# macOS/Linux
cd <YourRepoRoot>/ServiceConfigs/Deployment/config/pdp/policies

2

List the applications with policies:

# Windows
dir applications

# macOS/Linux
ls applications

You should see folders like it-shop, identity-governance, idp, etc.

3

Read an application-level policy:

# Windows
type applications\it-shop\principal-policy.json

# macOS/Linux
cat applications/it-shop/principal-policy.json

4

Explore the IGA application policies:

# Windows
dir applications\identity-governance
type applications\identity-governance\principal-policy.json

# macOS/Linux
ls applications/identity-governance
cat applications/identity-governance/principal-policy.json

✅ Expected Findings

principal-policy.json defines application-level rules using JSON IR schema
IGA subdirectories (guardrails/, sod/, etc.) contain category-specific policies
Each rule has an id, effect, conditions via $expr, and optional on_deny/on_permit context

🤔 Self-Check

What is the default effect for the it-shop application?
Which roles can modify products?
Are there any conditions defined in the policies?

LAB 2 Make AuthZEN Requests with curl ⏱️ 10 minutes

Let's make authorization requests directly to the PDP using curl.

1

Check if PDP is healthy:

curl -s https://pdp.self.empowernow.ai/health | jq .

2

Make a permit request (reading products):

curl -s -X POST https://pdp.self.empowernow.ai/access/v1/evaluation \
  -H "Content-Type: application/json" \
  -d '{
    "subject": {"type": "user", "id": "alice"},
    "action": {"name": "read"},
    "resource": {"type": "products", "id": "catalog"},
    "context": {"application": "it-shop"}
  }' | jq .

3

Make a deny request (deleting without permission):

curl -s -X POST https://pdp.self.empowernow.ai/access/v1/evaluation \
  -H "Content-Type: application/json" \
  -d '{
    "subject": {"type": "user", "id": "alice"},
    "action": {"name": "delete"},
    "resource": {"type": "products", "id": "product-123"},
    "context": {"application": "it-shop"}
  }' | jq .

4

Try a batch evaluation:

curl -s -X POST https://pdp.self.empowernow.ai/access/v1/evaluations \
  -H "Content-Type: application/json" \
  -d '{
    "evaluations": [
      {
        "subject": {"type": "user", "id": "alice"},
        "action": {"name": "read"},
        "resource": {"type": "products"},
        "context": {"application": "it-shop"}
      },
      {
        "subject": {"type": "user", "id": "alice"},
        "action": {"name": "write"},
        "resource": {"type": "orders"},
        "context": {"application": "it-shop"}
      }
    ]
  }' | jq .

✅ Expected Output

Read products: {"decision": true}
Delete products: {"decision": false}
Batch: Array of decisions for each evaluation

🤔 Self-Check

What happens if you change the application context to one that doesn't exist?
How would you give Alice permission to delete products?

LAB 3 Understand Policy Inheritance ⏱️ 10 minutes

Let's trace how policies inherit from each level.

1

Read the global security baseline (replace <YourRepoRoot> with your project root):

# Windows: type <YourRepoRoot>\serviceconfigs\pdp\config\policies\global\base-security-policy.json
# macOS/Linux: cat <YourRepoRoot>/serviceconfigs/pdp/config/policies/global/base-security-policy.json

This is Level 1—applies to ALL applications.

2

Read the application default:

# Windows: type <YourRepoRoot>\serviceconfigs\pdp\config\policies\applications\it-shop\principal-policy.json
# macOS/Linux: cat <YourRepoRoot>/serviceconfigs/pdp/config/policies/applications/it-shop/principal-policy.json

This is Level 2—applies to the it-shop application.

3

Read an IGA guardrail policy (resource type level):

# Windows: type <YourRepoRoot>\serviceconfigs\pdp\config\policies\applications\identity-governance\guardrails\contractor-restrictions.json
# macOS/Linux: cat <YourRepoRoot>/serviceconfigs/pdp/config/policies/applications/identity-governance/guardrails/contractor-restrictions.json

This is Level 3—applies to the guardrail resource type within identity-governance.

4

Trace the inheritance:

Does the resource policy have inherit: true?
If a rule matches at Level 3, does Level 1 still apply?
What happens if Level 1 says deny but Level 3 says permit?

✅ Key Insight

More specific policies (lower levels) override less specific ones (higher levels). A Level 3 permit can override a Level 2 deny, but not a Level 1 explicit deny. This is why "deny at the top" is a safe default.

🔧Troubleshooting Authorization

Authorization bugs are frustrating because they're often silent failures—no error message, just a 403. Here are the most common scenarios you'll encounter and how to debug them.

🚫 The Unexpected 403 Case #1

📋 Symptom

User gets 403 Forbidden despite having the correct role. They could access this resource yesterday!

🔍 Investigation

Check if the user's role assignment is still valid (membership service)
Verify the application context is correct in the request
Look for recent policy changes that might have added restrictions
Check if there's a condition (time-based, IP-based) blocking access

# Get detailed decision explanation
curl -s -X POST https://pdp.self.empowernow.ai/access/v1/evaluation \
  -H "Content-Type: application/json" \
  -H "X-Debug: true" \
  -d '{"subject": {...}, "action": {...}, "resource": {...}}' | jq '.context.reason_admin'

✅ Fix

Verify role assignment in membership: GET /users/{id}/roles
Check policy file for new conditions or rule changes
Clear the PDP cache if policy was recently updated

📝 The YAML Syntax Error Case #2

📋 Symptom

After editing a policy file, all authorization requests for that application return errors or unexpected denials.

🔍 Investigation

YAML is whitespace-sensitive—check indentation
Look for missing colons, quotes, or brackets
Verify the policy schema is correct (rules, subjects, actions)

# Validate YAML syntax
python -c "import yaml; yaml.safe_load(open('policy.yaml'))"

# Check PDP logs for parsing errors
docker logs pdp-app --tail 50 | grep -i error

✅ Fix

Use a YAML validator or IDE with YAML support
Keep a backup before editing policies
Test policy changes in a development environment first

🔄 The Inheritance Confusion Case #3

📋 Symptom

A rule you added at the resource level isn't taking effect. The global or application level seems to be overriding it.

🔍 Investigation

Remember the inheritance rules:

More specific levels can permit where less specific levels deny
But explicit denies at higher levels may override lower permits
Check inherit: true in your policy file

✅ Fix

Trace inheritance from Level 1 to Level 5 for your request
Use debug mode to see which rule matched
Consider if the rule should be at a different level

📦Rich Decision Context

A simple true/false isn't enough when a contractor is blocked from an admin group. The decision needs to explain why, suggest a fix, and optionally trigger automated actions. This is what on_deny.context, on_permit.context, and obligations provide.

Decision Response Anatomy

flowchart LR subgraph Decision["PDP Decision Response"] D["decision: true/false"] subgraph Ctx["context"] RU["reason_user
UI message"] RA["reason_admin
debug info"] GID["guardrail_id /
sod_violation"] REM["remediation
steps to fix"] end subgraph Oblig["obligations"] NOTIFY["alert_security"] REVOKE["auto_revoke_access
delay: 4h"] end end

Deny Response (Guardrail GR-001)

{
  "decision": false,
  "context": {
    "guardrail_id": "GR-001",
    "guardrail_name": "contractor_no_admin_groups",
    "risk_level": "high",
    "reason_user": {"en": "Contractors cannot be added to admin groups"},
    "reason_admin": {"en": "GR-001: Contractor attempted to join IT-Admins"},
    "remediation": "Remove admin group request or convert to FTE"
  }
}

Permit Response (Birthright BR-ENG-001)

{
  "decision": true,
  "context": {
    "naming_system": "av_entraid",
    "naming_object_type": "account",
    "birthright_groups": ["All-Employees", "Engineering-All"],
    "birthright_attributes": {"AccountEnabled": true, "UsageLocation": "US"},
    "licenses": ["Microsoft 365 E3"]
  }
}

Obligations (Automated Actions)

Some policies trigger automated side-effects alongside the decision:

"obligations": [
  {"type": "notification", "action": "alert_security",
   "parameters": {"priority": "high"}},
  {"type": "schedule", "action": "auto_revoke_access",
   "parameters": {"delay_hours": 4}}
]

Obligation Type	Action	Use Case
`notification`	`alert_security`	Emergency access triggers SOC alert
`schedule`	`auto_revoke_access`	4-hour auto-expiry for emergency grants
`audit`	`enhanced_logging`	Extra logging for high-risk decisions

❓Knowledge Check

Test your understanding before moving on. Click each question to reveal the answer.

1 What's the difference between authentication and authorization? ▼

Authentication answers "Who are you?" It verifies identity through credentials, tokens, or certificates.

Authorization answers "What are you allowed to do?" It determines permissions based on policies, roles, and attributes.

You must authenticate before you can authorize—the PDP needs to know who's asking before it can decide if they're allowed.

2 What are the four components of an AuthZEN request? ▼

Subject: Who is making the request (user, service, role)
Action: What operation they want to perform (read, write, delete)
Resource: What they want to access (document, API, feature)
Context: Additional attributes (time, IP, application)

3 What are the 5 levels of the policy inheritance hierarchy? ▼

Global: Applies to all applications
Application: Applies to a single application
Resource Type: Applies to a type of resource (e.g., all products)
Action: Applies to a specific action (e.g., delete)
Instance: Applies to a specific resource (e.g., product-123)

More specific levels override less specific ones.

4 Why is "default deny" a best practice? ▼

Default deny means: "If no rule explicitly permits this action, deny it."

This follows the principle of least privilege—users only get access they've been explicitly granted. It's safer than default permit because:

New resources are protected by default
Forgetting to write a policy doesn't create a security hole
You have to consciously decide to grant access

5 What are Policy Information Points (PIPs)? ▼

PIPs are external data sources that the PDP queries to make decisions. When a policy needs information not in the request, it asks a PIP.

Examples:

Membership service: "What roles does this user have?"
Resource metadata service: "Who owns this document?"
Time service: "What's the current time in the user's timezone?"

6 What's the difference between /evaluation and /evaluations endpoints? ▼

/access/v1/evaluation (singular): Evaluates a single authorization request. Returns one decision.

/access/v1/evaluations (plural): Evaluates multiple requests in a single call. Returns an array of decisions.

Use batch evaluation when checking multiple permissions at once (e.g., "What can this user do on this page?") to reduce network overhead.

7 Why does the PDP cache decisions? ▼

Authorization decisions are evaluated on nearly every API request. Without caching, the PDP would become a bottleneck.

Caching works because:

Most requests are repetitive (same user, same resource type)
Policies change infrequently
Cache can be invalidated when policies update

With caching, repeat decisions return in <1ms instead of 10-50ms.

8 What are the four IGA policy categories? ▼

Guardrails (GR-xxx): Pre-provisioning checks that block or allow actions (e.g., contractors can't join admin groups)
Separation of Duties (SOD-xxx): Detect toxic role combinations before assignment (e.g., payment approver + vendor manager)
Birthright (BR-xxx): Discover what systems/groups to provision based on HR attributes (e.g., Engineering FTE gets EntraID + AD + OpenLDAP)
Temporal (TEMP-xxx): Time-based constraints (e.g., contractor expired, max access duration)

9 Where does pdp_application go in an AuthZEN request? ▼

The pdp_application field goes inside resource.properties:

"resource": {
  "type": "group",
  "id": "IT-Admins",
  "properties": {
    "pdp_application": "identity-governance"
  }
}

This tells the PDP which application's policy set to load. Missing values default to "global". Invalid format returns HTTP 400; unknown application IDs return HTTP 422.

10 What is on_deny.context used for? ▼

on_deny.context provides rich metadata returned alongside a deny decision. It typically includes:

guardrail_id / sod_violation: The rule ID that triggered the deny
reason_user: A user-friendly explanation for the UI
reason_admin: Technical details for debugging
remediation: Steps to resolve the denial

Similarly, on_permit.context returns metadata for allowed actions — for birthright policies this includes which groups and attributes to provision.

📝Day 8 Checkpoint

Can explain what a PDP does and its role in authorization
Understand the AuthZEN request/response format
Know the policy file structure and organization
Can read and understand YAML policy syntax
Know the JSON policy format used by IGA policies
Can name the four IGA policy categories and their resource types
Understand pdp_application and rich decision context
Understand the 5-level inheritance hierarchy

💡 Want to Write Your Own Policies?

For hands-on PDP policy authoring, JSON IR, and application registration patterns, use the official EmpowerNow documentation together with your platform administrator.

📋Learning Objectives

🎯What is a Policy Decision Point?

Key Concepts

📜AuthZEN 1.1 Specification

Standard Endpoints

Standard Request Format

Standard Response Format

🚀The Authorization Request Journey

Step-by-Step Breakdown

📁Policy Structure

Application Scoping via pdp_application

Example Application IDs

🛡️IGA Policy Categories

🚧 Guardrails (GR-xxx)

⚖️ Separation of Duties (SOD-xxx)

🎁 Birthright Provisioning (BR-xxx)

⏱️ Temporal Constraints (TEMP-xxx)

IGA Resource Types

📝YAML Policy Syntax

Basic Policy Structure

Conditions

Time-Based Conditions

🔄JSON Policy Format (IGA Policies)

YAML vs JSON: Side by Side

JSON Condition Structure

Complete IGA Policy Example (GR-001)

🏗️5-Level Inheritance Hierarchy

Inheritance Example

🔬Hands-on Labs

🔧Troubleshooting Authorization

📦Rich Decision Context

Deny Response (Guardrail GR-001)

Permit Response (Birthright BR-ENG-001)

Obligations (Automated Actions)

❓Knowledge Check

📝Day 8 Checkpoint

Application Scoping via `pdp_application`