What do AGS Activation Condition and AGS Root Path determine?

Short answer

AGS Activation Condition determines which of the requests that come to the vService AGS is applied to: while it is empty (default), all the requests are in scope; if a condition is defined, in Standalone Application mode the requests that do not match the condition go to the Backend Service without a session being looked for. AGS Root Path is the path on which the login, verification and auxiliary pages of AGS are served (default /ags-portal); every request that starts with this path goes to the AGS engine regardless of the condition and the session, and does not enter the WAF scan. Since the matching is done with the text prefix, if there is a path that starts with the same prefix in the Backend Service, AGS Root Path should be changed.

How Does It Work?

For a request that comes to the AGS-enabled vService, the decision is made in the following order:

1. AGS Root Path: If the path starts with this value, the request goes to the AGS engine; the flow steps are served under this path with their own addresses (e.g. /ags-portal/form).
2. AGS Activation Condition: If a condition is defined and the request does not match the condition, the request is not directed to AGS.
3. Session: If there is no valid AGS session in a request within the scope, the request is taken into the login flow; if the session is valid, the request goes to the Backend Service.

The effect of the condition changes according to Gateway Mode:

Mode	A request that does not match the condition
Standalone Application	Goes to the Backend Service without visiting AGS.
Portal	If it does not match any of the Conditional Backend Services rules, it still goes to the AGS engine; the default target of the portal is the AGS engine.
Portal Application	If it has no session, it is redirected to the trusted portal regardless of the condition.

Activation Condition and Root Path in TR7

• Both fields are in the General Settings section of the General Settings window on the Flowchart tab of the AGS-enabled vService; the same fields are also edited in the mode section of the AGS Management tab.
• While AGS Activation Condition is empty, it reads Always. The conditions are selected from the Conditions records that belong to the HTTP request; the conditions within a group and the groups are combined with AND/OR. For example, to protect only the paths that start with /admin, a Path condition is selected.
• AGS Root Path is entered as a path that starts with /; if it is left empty, /ags-portal is used.
• The requests that do not enter AGS because they do not match the condition are counted on the Whitelisted /s card in the Access section of the Live Stats tab.

Common Misconceptions

• "The paths left outside the activation condition also require a login." In Standalone Application mode, the requests that do not match the condition never visit AGS and are accessed without authentication; the condition is written so that it covers all the paths to be protected.
• "AGS Root Path is only the login page." All of the form, verification, MFA and auxiliary pages are served under this path.
• "/ags-portal is caught only on an exact match." The matching is done with the text prefix; the /ags-portal value also covers the paths that start with /ags-portalx.

How it is done in the documentation

• Flowchart · AGS Activation Condition
• Flowchart · AGS Root Path
• Flowchart · How Does the Flow Work?
• Live Stats · Access

Related questions

• What happens to traffic when AGS is enabled on a vService?
• What is Gateway Mode; what is the difference between Standalone Application, Portal and Portal Application?
• If I put AGS in front of my application, does the application need code changes?
• What is the order when WAF and AGS are used together?