Policies
The Policies page (route /policies) manages the authorisation policies that control access beyond the basic permission grant: geo-IP restrictions, device rules, and how often resources require multi-factor authentication.
Purpose
A policy is a set of rules that apply on top of permissions. Where a permission says who may access a resource, a policy decides the circumstances under which that access is allowed, for example only from these IP subnets or always requiring multi-factor authentication. The Policies page lists your organisation’s policies and is where you create, configure, and delete them.
Why use it
- Enforce geo-location-based access control: allow or deny requests based on the source IP subnets and country codes.
- Require multi-factor authentication for specified resources, or for resources with particular labels.
- Apply time-based rules to how often authentication is needed.
- Implement firewall-style rules that grant or deny specific conditions (see the web guide’s Firewall rules).
When to use it
- When a resource or label must only be reachable from trusted networks or countries.
- When high-value applications must always challenge for multi-factor authentication.
- When you want automated, policy-driven decisions rather than individual exceptions.
- During security hardening, to add location and device restrictions.
Prerequisite: permission to administer policies (an owner or administrator role).
How to use it
- Open Access > Policies from the left navigation.
- Review the table. Each row shows the policy Type, Name, a human-readable Definition, a User Description, and an actions menu.
Creating a policy
- Select ADD AUTHORISATION POLICY. The Add Authorisation Policy wizard opens.
- On the first step, choose the policy type. Three types are available: Multi-factor authentication, Device information, and Time-based.
The rest of the wizard adapts to the chosen type. The Device information flow is:
- Name: give the policy a name.
- Device Information Configuration: choose whether the policy denies requests that do match or do not match your specified lists, then enter the IP subnets and country codes the policy applies to.
Each list is a chips field: type a value and click away to add it.
- Additional Configuration: optionally restrict the policy to resources with specific labels.
- Summary: review the policy definition before applying.
- Apply: select Add to save the policy.
The policy appears in the table with its generated definition.
Configuring an existing policy
Select the more menu on a policy’s row and choose Configure Policy. The same wizard opens with the policy’s current settings pre-loaded, and you can step through and change them.
Fields and controls reference
| Control | Purpose | Required | Default | Valid values | Notes |
|---|---|---|---|---|---|
| Type | The kind of policy | Yes | n/a | Multi-factor authentication; Device information; Time-based | Determines the configuration steps |
| Name | The policy’s name | Yes | n/a | Any text | |
| Definition | The generated human-readable rule | Read-only | n/a | n/a | Built from the configuration |
| User Description | A note for administrators | No | n/a | Any text | |
| My policy will | Whether the policy denies matching or non-matching requests | Yes | n/a | Deny requests that do match; deny requests that do not match | Device information policies |
| IP subnets | The source subnets the rule applies to | No | n/a | CIDR blocks | Chips field |
| Country codes | The countries the rule applies to | No | n/a | ISO country codes | Chips field |
| ADD AUTHORISATION POLICY | Opens the creation wizard | n/a | n/a | n/a | |
| DELETE POLICIES | Deletes the selected policies | n/a | n/a | n/a | Bulk action on ticked rows |
Dialogs and popups
- Add Authorisation Policy: the wizard described above.
- Configure Policy: the same wizard pre-loaded with an existing policy.
Configuration versus diagnostics versus confirmation
- Configuration: policy types, names, conditions, and the resources or labels they apply to.
- Diagnostics: the generated Definition column summarises what each policy does; there are no live diagnostics on this screen.
- Confirmation: deleting a policy is permanent and removes its rules. Applying a policy change takes effect asynchronously as the identity-aware proxy picks it up.
Pagination and async behaviour
- The table pages at 25 rows per page.
- Policy changes apply asynchronously. After creating or configuring a policy, wait a few seconds and reload to confirm. Access decisions change as the policy propagates.
Troubleshooting
- A policy has no effect: check the policy’s conditions and the resources or labels it applies to. Confirm the resources carry the expected labels (see Labels).
- Access is denied unexpectedly: review the policy definition; a deny policy blocks matching requests. Check whether the user’s requests match the listed subnets or country codes.
- Multi-factor authentication is not required: confirm the policy type and that it references the right resources or labels, and that at least one multi-factor authentication method is enabled (see Authentication policy).