Constraint Policies
What this screen is for
A constraint policy is a named set of conditions that limits how a capability grant may be used: when, how many times, how often, and whether only once. Policies are reusable, so several grants can reference the same one. This screen is your tenant's catalog of policies, where you create, edit and delete them.
A policy restricts nothing on its own. It takes effect only through the grants that reference it.
What must exist first
This screen is for tenants that compose authorization by hand. It is not offered to SIMPLE tenants: a SIMPLE tenant uses Internal Use Cases, which set up the conditions each use case needs.
Before you work here:
- The permission to list constraint policies, which is what shows this screen. Creating, editing and deleting a policy are further permissions, each held separately.
- Nothing else. A policy is created before the grants that will reference it.
Decisions you make here
Creating a policy
With the permission to create constraint policies, New Policy asks for a Name, which is required, an optional Description, and the conditions below. Every condition is optional. The conditions you set apply together: each use must satisfy all of them.
The conditions
- Valid From and Valid Until: a grant under the policy works only inside this window. Either side can be left open, and the end must be later than the start.
- Max Usage: how many uses each grant under the policy is allowed. Every authorized attempt counts, including one whose operation then fails, and the count never goes back down. Blank means unlimited; 0 allows no use at all.
- Rate Limit: how many uses per minute each grant under the policy is allowed. Blank means no rate limit; 0 blocks every use, which works as an emergency freeze.
- Revoke on use: the first use of a grant under the policy claims it, and further uses are refused for the following 24 hours. The grant is not revoked automatically and can be used again after that, so revoke it once its single use has happened if it must never work again.
Usage counts are kept per grant: two grants that reference the same policy each get their own allowance. A use refused by a condition is recorded in the audit trail with the condition that refused it.
Editing a policy
With the permission to update constraint policies, Edit in a policy's detail changes its name, description and conditions. Save Changes replaces every condition with what the form shows, so a field you clear removes that condition.
An edit is not guaranteed to reach grants that already reference the policy: a grant takes its limits from the policy when the grant is created, and can keep enforcing those. To be sure a grant enforces the edited limits, revoke it and create it again. The new grant starts its usage count from zero.
Deleting a policy
With the permission to delete constraint policies, Delete in a policy's detail removes it. The deletion is refused while an active capability grant or cryptographic exchange still references the policy, and the refusal says how many do, so revoke those first. Nothing loses its conditions silently. A deleted policy cannot be restored.
How it relates to other screens
A policy is attached to a grant when the grant is created, and only there does it restrict anything:
Cryptographic exchanges can also reference a policy, and one that has not ended blocks the policy's deletion.