Access control can optionally be applied by the Gateway when the user/device tries to use any of the actions defined in an entitlement.
The entitlement token always contains the access control criteria which are evaluated by the Gateway(s) protecting a Site. When the first packet is sent to the (protected) host, the Gateway assesses whether the relevant claims meet the given access criteria. If the result equates to true then the related actions (access rules) are allowed for the user's firewall instance. For example: only allowing access to a (protected) host during working hours, or requiring the user to re-enter their password before gaining access to sensitive resources.
Always Allow Action(s) is the default access control method for new entitlements. As the name implies, users will always get the action(s) specified in the entitlement. If this is changed then an alternative form of access control must be configured or the entitlement will never be enabled by the Gateway.
Risk based access is a way to set up access controls based on a user risk score (provided as a claim) which in turn will decide if the action(s) specified in the entitlement are to be allowed. For example: access may only be allowed if the user risk score is medium or low. When the risk score is high then the entitlement will be denied (block rule applies). If a user interaction has been configured in the risk matrix, this will provide a way for the user to unblock access by performing some sort of additional authentication.
The most powerful way to set up access controls is to use Condition based access. Conditions contain claims-based access criteria expressions that must equate to true for the action(s) specified in the entitlement to be allowed. For example: access may only be allowed if the user is working from an office-based IP address. When the criteria equate to false then the entitlement will not be allowed (block rule applies). If a user interaction has been configured in a Condition, this will be triggered when the access criteria equate to false. User interactions provide an alternative way for the user to unblock access - by updating claims or providing new claims that will now meet the access criteria. For example, providing multi-factor authentication could be an alternative method for gaining access if not working from an office-based IP address.
Access control is not a one-off check performed at sign-in; the Gateway regularly performs real time re-evaluations of the access criteria, e.g., when a token is renewed or a device claim changes or when new results appear from the name resolver. The access rules may get updated in response to any changes in these claims. It is also possible to set re-evaluation times, so criteria can be re-evaluated when required - maybe to see if a working hours claim has expired and if so block access.
What's the difference between access control and policy assignment?
Entitlement access control and policy assignment are conceptually the same but have different roles and functionality:
Gateway vs Controller evaluation
Policies control the assignment of entitlements. The claims-based assignment criteria are evaluated by the Controller at user sign-in and again at claims token renewal time.
Access Control can optionally be selected in entitlements. The claims-based access criteria are evaluated by the Gateway when the user/device tries to use any action which may be allowed or denied..
Dynamic vs static claims
A policy’s assignment criteria should rely on more static claims, which are less likely to change during a session, such as user claims (directory group membership, email address, etc.).
An entitlement access controls can rely on dynamic claims, which are known to change during a session, such as device claims (IP address, time of day etc.). User response claims (set by user interactions such as MFA) can also be included here.
User interactions
Controllers do not initiate any user interactions (apart from MFA at Sign-in) or handle the related user response claims (<Provided MFA>, <Retyped Password>, <Provided Reason>). So these claims are not available in policy assignment criteria nor in Criteria Scripts.
Gateways's access criteria expressions that return false can trigger additional user interactions via the client. User interactions are helpful for improving the user experience or for implementing step-up authentication. For example, the client can display a message explaining why the action is denied, or request a password input before allowing the action.
Criteria scripts
Script mode is available within each policy's assignment criteria expression. Reusable scripts can be uploaded or created using the Criteria Scripts form and then reused in many Policies by selecting the criteria script from the assignment pick list.
Script mode is available within a condition's access criteria expression. The condition can then be reused in many entitlements.
For more information about how these fit into the overall authentication model used in AppGate ZTNA, refer to SPA & multi-stage authorization
Before setting up any access control it is worth considering the potential implications for the overall performance of the system.
If a user has very many complex entitlements then re-evaluating these is a non trivial task. If you have 1000 users on a Gateway each with 100 entitlements then this requires 100,000 evaluation events. And if these entitlements are scripted, then the Gateway may need to make 100,000 external API calls as well. This scenario might be OK if the users sign-in to the Gateway gradually - but if there is a failover then these 100,000 events may take a considerable time to process (possibly many minutes).
A device claims script is checked every 5 minutes - if this returns unstable results (such as returning the whole process list or the current time), then because the results will have changed every time a re-evaluation has to be performed. With 2000 users each with 10 entitlements you now have a system performing 4,000 re-evaluations per minute. If these involve an external API call then the Gateway will be making 67 API calls/sec, adversely affecting the user experience. For more information, see Real time (re)evaluations.