The AppGate ZTNA system easily supports most access control requirements - from the simplest VPN replacement using <Always Allow Action> all the way up to complex dev-ops deployments using scripts. The easiest way to understand this is to consider AppGate ZTNA as having three main access control modes that can be used:
<Always Allow Action> - This is the default option, and relies on the Policy assignment criteria only to limit the access rights within an Entitlement.
<Risk Based Access> - This provides easy to use access control based on a user risk score which is usually matched to the sensitivity of the (protected) host a simple risk matrix.
<Condition Based Access> - Access rights within an Entitlement will be allowed when one or more selected Conditions equate to 'true' using either <all below are true> or <any below are true> logic. This has three configuration options:
No Condition specified in which case no access will be allowed.
Condition based access using List mode for the criteria expressions where; <at least one of the criteria below must be true>, <all criteria below must be true> or <Criteria are met according to Custom Logic>.
Conditions using the Script mode option written in JavaScript.
Risk based access
NOTE
Risk Model has been deprecated. However, you can still use risk scores for access control.
Use the Risk Model UI to create and change basic access controls.
The Risk Model is used in Entitlements and provides an alternative way to control access. It provides a simple way to map the User Risk (measured when a user signs in) against the sensitivity of the host defined in the Entitlement.
This allows dynamic access control to be used without the needed to deep dive into access criteria expressions and Conditions. Normally the outcome is derived from just two inputs sensitivity and user risk.
Sensitivity
Sensitivity is set in Entitlements > Access Controls. When Risk Based Access is selected the outcome for each level of sensitivity (based on user risk) is defined by this matrix.
Think of Sensitivity as being how 'available' you want to make each protected host. A low sensitivity protected host might be available to everyone all the time.
There is a Bulk Action available in Entitlements which allows you to assign the sensitivity to multiple Entitlements in one go.
User Risk
User risk claim value will trigger the outcome defined in one of the three columns High (3), Medium (2) and Low (1).
There are two sources for the user risk score:
User risk can be based on the claim claims.user.agScripted.risk.score which is the output from a user claim script. You can configure your own script to return a number between 1and 3.
ZTP integration will automatically populate and use the (internal) claims.user.ag.risk.score which is populated from a specific rule configured in ZTP.
If there is an issue with the ZTP provided scores, then the AppGate ZTNA system assumes a score based on the fall back settings that were set when AppGate ZTNA was linked to ZTP.
Using the Risk Matrix
| No user risk score Even without a user risk score you can use the risk matrix in a very simplified way. All users will be assumed to be High user risk (3). So it will just use the first column and there you should set either the <USER ACTION> or <ALLOW> options. <DENY> makes no sense in this scenario as you might as well have not bothered to create the Entitlement in the first place as it will never be allowed. In this example high sensitivity Entitlements will require a user interactions and all other will be allowed. |
When a user interaction is triggered by the risk model then under the covers this will work in exactly the same way as if you were configuring one in a Condition. The difference in the case of the risk model is that most of the configuration is done for you. The user response claim is automatically generated and checked in (hidden) access criteria expressions. The user response claim is set to be valid for 240 minutes (1/2 a day) and the periodic re-evaluation is set for 15 minutes.
| With user risk score Once the user risk score is available you can use the risk matrix in its intended way. Typically <DENY> will be used in the top left and <ALLOW> the bottom right, with <USER ACTION> positioned where additional authentication can be used to mitigate the user risk. Effectively the <USER ACTION> becomes an <ALLOW> once the user interactions action has been successfully performed.
|
.png?sv=2022-11-02&spr=https&st=2026-04-16T22%3A51%3A29Z&se=2026-04-16T23%3A09%3A29Z&sr=c&sp=r&sig=M80toTAqpT3KTd4AaY1W9JujDerhcwBP08usD9kR5HE%3D)
There is only one risk matrix available in a Collective. So if you have two different scenarios to address which cannot be satisfied with the one risk matrix configuration, then you will have to use Conditions for the Entitlements requiring the alternative scenario.
To this end, Access Criteria includes a context based helper for ZTP Risk Rules. This allows Conditions to be used in almost exactly the same way as if the Risk Matrix had been used.
Under the covers
The risk matrix is actually using nine hidden access criteria expressions/Conditions to evaluate these claims. All the parameters used in access criteria expressions are still there (and used) but the system automagically generates these and uses preset default values such as the user response claim remains valid time period, which is preset to 240 minutes (4 hours).
Three Conditions always apply at any one time as the Entitlement can have only one sensitivity level, but may have three user risk scores. The three Conditions that apply use AND logic so All Conditions must be met for access to be allowed.
| In this example; for a user accessing a medium sensitivity protected host and presenting a medium risk score (2) the session details would look like this. High and low user risk does NOT apply so these are deemed to be true. The medium user risk applies in this case and is deemed to be false at this time because a user interaction is required - and this has NOT YET been performed by the user. Once this has been performed then all three access criteria expressions will be true and access will be allowed. |
Condition based Access
Use the Conditions UI to create and change access controls.
Conditions are created using access criteria expressions which in turn comprise claims-based evaluations such as Day of week is Tuesday.
Criteria expressions have three different combining modes (without using scripts):
<all criteria below must be true> - a logical AND of different criteria needs to equate to true
<at least one of the criteria below must be true> - a logical OR of different criteria needs to equate to true
<Criteria are met according to custom logic> - a simple Boolean expression comprising a number of different criteria needs to equate to true
Examples of how to combine access criteria to control access
Example 1. Restrict access only to devices connected to the office network during working hours
All criteria in one Condition with that Condition added to the appropriate Entitlement.
| Expression | Parameters |
|---|---|---|
Condition "Office hours restricted access" | Allowed when <all criteria below must be true> |
|
Access criteria | Time is between clientSrcIPs is in network | 09:00AM - 05:00PM (network in CIDR) 10.0.0.0/24 |
Entitlement "Working from office" | If <all criteria below must be true> |
|
Condition | Office hours restricted access |
|
Example 2. Restrict access only to devices connected to the office network during working hours
Two individual Conditions which are then combined together using all below are true within the appropriate Entitlement.
| Expression | Parameters |
|---|---|---|
Condition "Office Hours" | Allowed when <all criteria below must be true> |
|
Access criteria | Time is between | 09:00AM - 05:00PM |
Condition "Office network" | Allowed when <all criteria below must be true> |
|
Access criteria | clientSrcIP is in network | (network in CIDR) 10.0.0.0/24 |
Entitlement "Working from office" | Allowed when <all criteria below must be true> |
|
Condition | Office hours Office network | (within office hours AND connected to the office network) |
Example 3. Adding a user interaction to provision access outside office hours
Two individual Conditions, one containing a user interaction which are then combined together using any below are true within the appropriate Entitlement.
Expression | Parameters | |
|---|---|---|
Condition "Office hours restricted access" | Allowed when <all criteria below must be true> |
|
Access criteria | Time is between clientSrcIPs is in network | 09:00AM - 05:00PM (network in CIDR) 10.0.0.0/24 |
Condition "Evening access MFA" | Allowed when <all criteria below must be true> |
|
Access criteria | Time is between Provided MFA | 05:00pm - 09:00AM (named) general (less than) 60 (minutes ago) |
User Interaction | Require MFA | (named) general (with text) "Enter a valid MFA" |
Entitlement "Restricted finance access" | Allowed when <at least one of the criteria below must be true> |
|
Condition | Office hours restricted access Evening access MFA | (within office hours AND connected to the office network) (outside office hours AND a valid MFA has been entered in the last 60 minutes) |
Access Criteria Scripts
Use the Conditions UI to create a new script.
The Gateways evaluates any access criteria expressions included in Conditions to make access decisions. If true, then the Actions are allowed; if false: a user interaction may be initiated and sent to the Client.
There is no requirement to write a script - expressions can be configured within the Condition itself using the criteria tool options and claims pick-list. This will generate the resulting JavaScript expression for you. However, when an access criteria script is used, it can combine existing user, device and system claims with extra dynamic information and make complex access decisions in near real-time. Again, it executes in a sandboxed JavaScript engine with httpGet/Post/Put/Delete calls allowed.
When using a script, it should be as efficient as possible as every time a user opens a new TCP stream the script will be run. Instead of using http(s) calls to get static claims (i.e. user group), consider using a User claim script as this will only be run once per sign-in and the Controller will add any new claims to the claims token. This will reduce the latency caused by the Gateways having to make frequent (unnecessary) external API calls.
Scripts may request information from other systems that require credentials (which will have to be included in the JavaScript). Scripts used in Entitlements and Conditions are therefore passed in the encrypted portion of the Entitlement token.
Why use?
There are several reasons why you might want to use a criteria script (as opposed to just a Boolean expression).
The complexity of the Boolean expression required goes beyond what the builder can support.
You switched from list mode's <Criteria are met according to Custom Logic> to script mode and made an edit.
An external call is required to harvest claims from some other third party system.
NOTE
Script mode is available for very advanced use cases. However this may break compatibility with the other three modes.
To configure
Enter the JavaScript directly in Conditions under Access Criteria by selecting <Switch to Script Mode>. Refer to Claims in detail and External https calls for more details. (e.g. convert an IP Address to a country code).