How is AGS used together with Load Balancer conditions and the WAF?

Short answer

AGS works with Load Balancer conditions in two directions on the same HTTP vService. The settings of AGS itself are built from Conditions records: AGS Activation Condition determines which requests come into the scope of AGS, the Decision Point in the Flowchart determines which branch the flow goes to, and the Backend SSO conditions determine which request the identity information is added to. On the Load Balancer side, the AGS Condition criterion (with variables such as AGS username, AGS user groups and AGS user attribute) and the ready-made IF is an authenticated AGS user condition let the Actions and Conditional Backend Services rules of the vService and the condition fields of the WAF decide based on the AGS session. When AGS is on together with the WAF, the login and verification pages under AGS Root Path are not subject to WAF inspection; the requests of a user whose session is authenticated, on the other hand, are fully inspected in the WAF.

How Does It Work?

The AGS session is verified when the processing of the request begins; for this reason, conditions based on AGS can be used in all the later stages. The order of the stages and their relationship with the WAF: What is the order when WAF and AGS are used together?

1. The AGS session is determined: Whether the client has a valid AGS session is established, and the user information in the session is prepared.
2. WAF scan: Requests that do not start with AGS Root Path are scanned in the WAF regardless of the session state.
3. Actions: Actions that contain an AGS condition are evaluated at this stage; an action that terminates the request runs before the login redirect of AGS.
4. Target selection: A request that is within the AGS scope and has no session is taken into the login flow. For requests that have a session, the Conditional Backend Services rules are evaluated; a different Backend Service can be selected according to the user group.

AGS, Condition and WAF in TR7

Direction	Where	What for
Condition → AGS	AGS Activation Condition (Flowchart → General Settings)	Taking only specific paths or hosts into AGS; requests that do not match the condition go to the Backend Service without passing through AGS. Requests under AGS Root Path go to AGS regardless of the condition.
Condition → AGS	Decision Point step	Splitting the flow into YES / NO branches according to a condition (e.g. not asking for a second factor from those coming from the internal network)
Condition → AGS	Backend SSO Condition, Backend session lost condition, Backend logout condition	Adding the identity information only to specific requests; following the session according to the response of the Backend Service
AGS → Load Balancer	Actions + AGS condition	Adding a header, redirecting or blocking according to the user or the group
AGS → Load Balancer	Conditional Backend Services + AGS condition	Routing to a different Backend Service according to the group (e.g. the admins group to the management servers)
AGS → WAF	WAF condition fields + IF is an authenticated AGS user	WAF decisions such as showing a different blocking page to a logged-in user

AGS condition is used only on an HTTP vService; it can be defined on a vService where AGS is not enabled, but since there is no session to evaluate, it never matches.

Common Misconceptions

• "An action is needed to send those who have no session to the login." AGS does this redirect itself. If a blocking action is additionally set up with the Unless is an authenticated AGS user condition, AGS Root Path is excluded in the condition of the action; otherwise the requests coming to the login pages also enter the action.
• "The WAF does not inspect a user who has logged in to AGS." The requests of an authenticated user are also fully inspected in the WAF; the WAF and AGS do not replace each other. If the IF is an authenticated AGS user condition is placed in the Whitelist Condition field of the WAF, all the requests of logged-in users are excluded from WAF inspection.
• "Requests outside the AGS Activation Condition are unprotected." These requests merely do not pass through AGS; the WAF and the other rules of the vService are applied to these requests too.
• "A separate AGS setting is needed for routing by group." The group information is in the session; an AGS condition built with the AGS user groups variable is used in a Conditional Backend Services or Actions rule.

How it is done in the documentation

• AGS Condition · What Is AGS Condition?
• Flowchart · AGS Activation Condition
• Flowchart · Decision Point
• AGS - AAM · The Difference from WAF and Bot/DDoS

Related questions

• What is the order when WAF and AGS are used together?
• What do AGS Activation Condition and AGS Root Path determine?
• What is the difference between Decision Point and Switch in the Flowchart?
• Which stages does a request go through inside TR7 before it reaches the backend?
• What is a Smart Variable; how is it used in conditions and actions?