← All practicals

Your policy, actually enforced

Wire the policy PDP into a REAL protected resource — and watch payroll stay denied until IDV raises your clearance.

1. 1

   Open the PEP lab and read your own server-derived subject: your id, and a clearance derived from your latest IDV result.

   A real Policy Enforcement Point never lets you assert who you are — your subject is built entirely from your session and your OWN idv_sessions row, never from anything the request body sends.

2. 2

   Access the handbook — the starter policy lets anyone READ, so it comes straight back with its content.

   The SAME rules you see on the Policy PDP lab now govern a REAL access decision, not just a sandbox evaluation — edit a rule there, and it changes what you can reach here. Delete that read allow and the handbook goes to default-deny: nothing here is allowed unless a rule says so.

3. 3

   Try payroll — refused, by a starter rule you did not write. Then author your OWN deny on /policy (resource.classification == restricted and subject.clearance != ial2) and try again.

   The first refusal is the starter deny on restricted resources; your rule makes the same call in your own words. Now TWO deny rules match, and the reason says so — deny overrides any allow, and it does not matter how many allows there were or which rule got there first. That is the whole of deny-overrides, shown rather than asserted, with the PDP naming exactly which rules refused you instead of a vague "no".

4. 4

   Complete identity verification at ial2 on /idv, then access payroll again.

   Your clearance is re-derived live from your latest IDV session on every single decision — nothing to refresh, nothing cached. BOTH deny clauses stop matching at once, the read allow is the only rule left standing, and payroll unlocks for real.