What is the difference between the Load Balancer and AGS; where does AGS work within the Load Balancer?
Short answer
Load Balancer - ADC decides which Backend Service the request goes to; AGS - AAM, on the other hand, asks who is sending the request and does not let a user whose identity has not been verified reach the Backend Service. AGS is not a separate device or address: it works inside the same HTTP vService, at the target selection stage after TLS is terminated. A request without a session is directed to the vService's AGS engine instead of the Backend Service; a request with a valid session goes to the Backend Service through the usual target selection of the Load Balancer.
How Does It Work?
On an HTTP vService with AGS enabled, the request passes through the stages of the Load Balancer in the same order; the AGS decision is made at target selection:
| # | Stage | With AGS enabled |
|---|---|---|
| 1 | Reception and TLS termination | Unchanged. The AGS pages are served with the vService's own address and certificate, under AGS Root Path (default /ags-portal). |
| 2 | Security layers and request Actions | WAF, L7 DDoS & Threat Protection and request actions also run for requests without a session; only the requests under AGS Root Path are kept out of the WAF scan. |
| 3 | Target selection | Requests that start with AGS Root Path go to the AGS engine regardless of the session state, and other requests without a session go to it if they match the AGS Activation Condition (all of them if the condition is not defined). If AGS Activation Condition is defined, in Standalone Application mode, requests that do not match the condition go to the Backend Service without a session being looked for. A request with a valid session finds its target with Conditional Backend Services and Default Backend Services. |
| 4 | Forwarding to the Backend Service | Algorithm and Persistence work in the usual way. AGS cookies are removed from the request; if a Backend SSO profile is bound, the credentials are added. |
All stages: Which stages does a request go through inside TR7 before it reaches the backend?
Comparison
| Load Balancer - ADC | AGS - AAM | |
|---|---|---|
| The question it answers | Which Backend Service should the request go to? | Who is sending the request, and can they access? |
| vService type | Network, L7 TCP and HTTP | HTTP only |
| Decision unit | Each connection or request | Session; the identity is verified once per session |
| User verification | HTTP Basic Auth with the User Authentication (On HTTP request) action | Login flow: form, nine Authentication Provider types, MFA, session and lockout policies |
| Product | TR7 ADC | TR7 AAM (Products & Licensing) |
AGS and the Load Balancer in TR7
- AGS is enabled with the AGS box in the Details list of the vService form; the Backend Services, Algorithm, Persistence and Actions settings of the vService do not change.
- After the session is opened, the user information can be used in Load Balancer rules: with the AGS Condition condition and AGS variables such as
%AGS_USERNAMEand%AGS_GROUPS, a Backend Service is selected or access to a path is restricted according to the group (How is AGS used together with Load Balancer conditions and the WAF?). - On a vService in Portal mode, the default target is the AGS engine: requests that have a session and do not match the Conditional Backend Services rules go to the portal page, not to Default Backend Services (What is Gateway Mode; what is the difference between Standalone Application, Portal and Portal Application?).
Common Misconceptions
- "AGS is a separate layer placed in front of the Load Balancer." AGS works inside the same vService; it does not require a separate IP address, port or device.
- "When AGS is enabled, the Load Balancer rules are skipped." WAF, L7 DDoS & Threat Protection and request Actions also run for requests without a session; AGS changes only the target.
- "Basic Auth in the Load Balancer and AGS do the same job." User Authentication (On HTTP request) opens the browser's Basic Auth window; AGS, on the other hand, offers a login page, external identity sources, MFA, and session and lockout management.
How it is done in the documentation
