Today, Policy APIs return configured policy state (local entries + imports config), but not the final resolved policy view after imports are applied.
This issue proposes a follow-up API capability to retrieve the effective/resolved policy.
Current behavior
GET /api/2/policies/{policyId} returns stored policy config.
GET /api/2/policies/{policyId}/entries returns local entries only.
Imports config is visible, but effective merged entries are not directly visible.
Problem
- Difficult to debug and validate authorization behavior.
- Hard to explain effective access when imports and additions are involved.
- Operational/support troubleshooting requires internal knowledge.
Proposal
Add a read API/view that returns the effective resolved policy after:
- import resolution (implicit / explicit / never)
- entriesAdditions merge logic
- allowed additions constraints
Possible shape (one option):
GET /api/2/policies/{policyId}?view=resolved
Alternative:
GET /api/2/policies/{policyId}/resolved
Expected output (high level)
- Fully resolved entries used for enforcement.
- Optional metadata per entry (e.g. local vs imported origin: policyId + entry label).
- Clear indication of what was ignored due to import rules (if feasible).
Today, Policy APIs return configured policy state (local entries + imports config), but not the final resolved policy view after imports are applied.
This issue proposes a follow-up API capability to retrieve the effective/resolved policy.
Current behavior
GET /api/2/policies/{policyId}returns stored policy config.GET /api/2/policies/{policyId}/entriesreturns local entries only.Imports config is visible, but effective merged entries are not directly visible.
Problem
Proposal
Add a read API/view that returns the effective resolved policy after:
Possible shape (one option):
GET /api/2/policies/{policyId}?view=resolvedAlternative:
GET /api/2/policies/{policyId}/resolvedExpected output (high level)