Use the Conditions UI to set re-evaluation times.
The Appgate SDP system is designed to re-evaluate access rights in real time. Examples that might trigger a re-evaluation are:
a user's situation changes (moves networks)
the resources in a protected network change (name resolver)
a device claim changes (firewall turned off)
a new Policy is created and pushed out by an administrator (Token renewal)
Real-time control of access
The access criteria set in a Condition defines when the Appgate SDP system will enable that Entitlement for the user. The system always triggers an evaluation of the access criteria when the user attempts to access the resource. If successful, then the system has various completely automated triggers which will re-evaluate the access criteria at the required points in time (e.g. on a network change. Clearly, the exact times of these re-evaluations is somewhat unpredictable! With more complex the access criteria, these re-evaluations are likely to happen more frequently. With very simple access criteria then it's possible the first re-evaluation will not happen until the user's tokens expire.
For many situations the system will look after itself and not require any additional time based re-evaluations to be configured. However there are some situations where you might want to do this.
Setting Re-evaluation times
There are only a few situations where it is required to set re-evaluation times. Here are some examples where it might be required:
When using an access criteria script which returns values which change frequently.
When setting a Condition that relates to an absolute time.
To make sure the MFA and Password Conditions (which specify a lifetime during which the user response claim will be deemed to be true) are honored.
The system already has numerous triggers which trigger (re)evaluations automatically as shown across the top of the diagram below. The use of any additional re-evaluation times set needs to strike a balance between being too exacting (in terms of time accuracy) and not meeting the spirit of any security policy you want to enforce. The checking process is a very compute intensive task so setting very short/frequent re-evaluation periods will add considerable load on the Gateways. A bad configuration would be to set up a condition 'after 17:00' then set a periodic reevaluation every 5 minutes to check this.
Before we look at when you should set re-evaluation times we need to understand how the user interactions and the related user response Claims (<Provided MFA>, <Retyped Password> work. When a user interaction is performed the user response claim is given a time stamp which is at the next 1/4 hour. So if the user enters their password at 14:32 then the claim will carry a time stamp of 14:45. This makes setting a periodic re-evaluation of 12 times per hour pointless.
To prevent users simply being disconnected when one of these re-evaluation events determines the claim has expired, the system actually has a 5 minute warning event. The Gateway checks whether the Condition will still pass in 5 minutes time and during this time window will re-trigger the user interaction (before the Condition actually fails) preventing the users session being lost by any change in the firewall rules.
Time of Day for Re-Evaluation (UTC)
The Gateway will re-evaluate a user's claims at these times. Required if the access criteria includes a temporal element such as 'only after 17:00'.
In this example the Condition includes time based access criteria between 8:30 and 17:00. A Specific re-evaluation time is set for 17:01 so that this condition will fail at that time and access will no longer be available. The other occasion when specific times might be useful is when an external criteria script needs to be run at a particular time.
.png?sv=2022-11-02&spr=https&st=2026-04-16T22%3A48%3A55Z&se=2026-04-16T23%3A04%3A55Z&sr=c&sp=r&sig=hSxgvBcYGX2mzKxOL0vzGO7Hif748dBL26OK0oWFq9I%3D)
Periodic Re-Evaluation (UTC)
The Gateway will re-evaluate a user's claims periodically. Mainly required when using password and MFA user interactions to check if the related claims are still valid.
This is also useful in the case where an external access criteria script is used and the values returned are known to change frequently.
In this example the Condition includes Provided MFA within 60 minutes. A periodic re-evaluation time is set for on the quarters so this Condition will eventually fail (unless another user interaction is performed) and access will no longer be available.
Periodic re-evaluations are not related to the time the user performed the user interactions but to UTC, this means the next <on the hour> evaluation might happen any time from a second or two later up to almost an hour, depending on when the initial evaluation took place. To make the outcomes more deterministic user response claims are always timestamped at the next quarter of an hour. So if a password was required every 60 minutes and it was entered at 14:32, then the <on the quarters> setting would trigger the next user interaction at 15:40 (5 minutes before 15:45). If the user responded at this time then the new claim will carry a time stamp of 15:45 and the next user interaction will happen at 16:40 (5 minutes before 16:45).
Because user response claims are always timestamped at the next quarter of an hour then the <on the quarters> setting is the best one to use for shorter periods (required up to every 6 hours). If a longer period is set then the <on the hour> should be used.
The <12 times per hour> is likely only to be required with the use of external criteria scripts.
When Risk based access is used this defaults to 'On the quarters'.
Refer to Access control for complete usage information.
Table of (re)evaluation triggers
To sense these changes several aspects of the system can be configured to manually or automatically update a user's access rules without any user intervention. The table below shows what 'triggers' cause a (re)evaluation and the effect that (re)evaluation will have.
Trigger | When (default) | Policies | Claims | Entitlement | Entitlement script run | Firewall rules (Gateway) |
|---|---|---|---|---|---|---|
Client sign-in (to Controller) | by user/device | y | y | y | n/a | n/a |
Client connects to Gateway | by Client | n | n | n | y if conditions = true | Session added |
user access or not (i.e OTP) | n | y for OTP and password | n | y if conditions = true | y | |
every 5 minutes (fixed) | n | n | n | y if change reported & new condition = true | y if change reported | |
0/5/15/60 minutes | n | n | n | y if conditions = true | y | |
@time (i.e. 17.00) | n | n | n | y if conditions = true | y | |
every 24 hours or ?? | y | y | n | y if conditions = true | y | |
every 24 hours or ?? | y | n | y | y if conditions = true | y | |
every 60 seconds or ?? | n | n | n | y if change reported & condition = true | y if change reported | |
Alert triggered | by behavior | n | n | n | y if conditions = true | y |
Token renewed | by admin (admin can choose) | y | y | y | y if conditions = true | y |
Client reconnect | sleep/HA | n | n | n | y if conditions = true | y |
Client reconnect | roaming (IP change) | y | n | y | y if conditions = true | y |
Client sign-out | by user/device | n | n | n | n | Session removed |
Follow the links provided to take you to the section where you can set the trigger parameters.