Real-time reevaluations

Use the Conditions UI to set reevaluation times.

The AppGate ZTNA system is designed to reevaluate access rights in real time. Examples that might trigger a reevaluation 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 ZTNA 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 reevaluate 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 reevaluation 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 reevaluations to be configured. However there are some situations where you might want to do this.

Setting Reevaluation times

There are only a few situations where it is required to set reevaluation 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 reevaluations automatically as shown across the top of the diagram below. The use of any additional reevaluation 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 reevaluation 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 five minutes to check this.

Before we look at when you should set reevaluation 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 quarter 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 reevaluation of 12 times per hour pointless.

To prevent users simply being disconnected when one of these reevaluation events determines the claim has expired, the system actually has a five minute warning event. The Gateway checks whether the Condition will still pass in five minutes time and during this time window will trigger the user interaction again (before the condition actually fails) preventing the users session being lost by any change in the firewall rules.

Time of Day for Reevaluation (UTC)

The Gateway will reevaluate 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 reevaluation 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.

Periodic Reevaluation (UTC)

The Gateway will reevaluate 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 reevaluation 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 reevaluations 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 (five 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 (five 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 six 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 reevaluation 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 reevaluation and the effect that reevaluation will have.

• Follow the links provided to take you to the section where you can set the trigger parameters.