support wildcard matching like https://*.example.com/*
apply only to HttpAccess events
Step-by-Step: Create an HTTP Access policy (via Advanced JSON)
1
Navigate to Endpoint Privilege Manager → Policies
2
Click Create Policy Button
This will spawn the Create Policy modal form.
3
Define Policy Attributes
Choose a aptly discriptive name for your new policy.
Choose any existing policy type available in the UI for your new policy(this is just a starting template since Update Settings is set in JSON).
Choose a status for your new policy. We recommend monitor mode when initially setting up a policy.
Add one or more Controls by clicking on the "Add Control" button and then selecting the controls that you would like to see applied to your new policy.
Choose a User Group, a Machine Collection, and an Application Collection.
4
Configure Policy Targeting
Configure any targeting you want in the UI (collections/users/machines/apps/platforms). Who or What does your policy apply to?
5
Open the Policy’s Advanced Mode (JSON view)
To open the Policy's Advanced Mode, click on the "Advanced Mode" link in the bottom left corner of the Policy Form.
6
Redefine Policy Type in JSON
Set: PolicyType to "HttpAccess"
7
Configure URL Filtering
Configure URL filtering using the policy’s URL filter field(s) in JSON (exact JSON key names vary by implementation, but the evaluator uses URL patterns and wildcards as described)
8
Save the Policy
Important note about field names
The attached docs clearly describe how URL filtering works, but they do not provide a canonical, copy/paste JSON schema for where URL patterns live in the policy JSON (i.e., the exact property name/path used in exported server policies vs. local policy templates). The “Raw Policy Template Format” shows a generic Filters: [ { UserCheck..., MachineCheck..., ApplicationCheck... } ] structure, but doesn’t include an explicit URL example.Administrators
So, the examples below are representative and align with the documented behavior (PolicyType + URL patterns + optional user/machine/application targeting). You’ll want to adjust the URL pattern field name to match what your Admin Console generates in the Advanced tab.
Example JSON Snippets
Example 1: Allow Only Specific Domains (allowlist)
What this intends: allow matching URLs; deny everything else (Default: "DENY").
Example 2: Block Specific Domains (denylist)
What this intends: when a URL matches any pattern, deny it.
Example 3: Block a Domain Only for a Specific App (app-scoped)
In this shape, app scoping is done via the existing ApplicationCheck targeting you already use elsewhere (the HTTP match then happens via Extension.UrlPatterns).
Example 4: Monitor-Only HTTP Access (no block, just notify)
This is useful when you want to stage rollout: match URLs and display a notification without enforcing deny.
Frequent Quick “drop-in” Edits
PolicyId: keep the ID generated by the UI.
Status: "on" or "off" depending on rollout.
UserCheck, MachineCheck, ApplicationCheck: fill these arrays using the same targeting entries your console normally writes.
Extension.UrlPatterns: your allow/deny patterns.
Validation tips
Test with an explicit URL first, then widen with wildcards.
Remember query strings are stripped during normalization, so patterns should usually avoid query parameters.
