Skip to main content

Verify an access decision

Use Console Live Testing in an existing non-production app. The result is a repeatable ALLOW/DENY decision pair for one saved conditional resource policy; you do not need application code or a runnable workload.

Prerequisites​

  • The target site and app are known, and the existing non-production app has a saved conditional resource policy whose condition compares request.resource.attr.status with "active".
  • An active site user is available whose assigned role and caller attributes match the rule's intended actor inputs.
  • The policy exposes a concrete entity:name resource and one action that the site user can perform only when the condition matches.

If any prerequisite is missing, first use Add policy conditions. Do not improvise a resource name or test an unsaved policy definition.

Live Testing includes an editor

The Policy YAML panel is editable, and Save replaces the full policy definition. A verification-only run must not select Save.

Verify the two decisions​

  1. In the target app, open the Policies list. On the saved policy row, select Live test this policy. Its tooltip is Live testing (saved policy).

  2. Under User, select the active site user and confirm the displayed roles match the expected assignment.

  3. Under Resource, confirm the policy's entity:name resource.

  4. Under Actions, clear the preselected actions and leave exactly one action that your condition controls. The editor starts with several actions selected, which would make this two-case check ambiguous.

  5. Under Attributes (optional), enter the first JSON object:

    {"status": "active"}

  6. Select Run Check. In Check results, record the first result as ALLOW.

  7. Change exactly one attribute by replacing the JSON object with:

    {"status": "inactive"}

  8. Select Run Check again. Record DENY for the same User, Resource, and Actions selection.

Expected result​

The expected result is an ALLOW followed by a DENY with only status changed. Retain both inputs and both Check results with the policy review. An authenticated user is not automatically authorized, and an ALLOW-only test does not prove that the condition protects the resource.

For the complete validation workflow, see Test access decisions. If either result is missing or unexpected, use Troubleshooting access policies and stop the release check until the policy, user, resource, and attributes are reconciled.