What is AGS - AAM and what does it do?

Short answer

AGS - AAM is the access control module that passes the requests coming to an HTTP vService through authentication before they reach the Backend Service; authentication is taken out of the application and moved to the vService. A user without a session is taken into the flow set up on the Flowchart tab of the vService: the user's identity is verified with an Authentication Provider, MFA is requested if necessary, and if the flow ends with Allow, a session is opened. The requests of a user with a session are forwarded to the Backend Service; if the application needs to recognize the user, the identity is added to the request with Backend SSO. AGS is enabled separately for each HTTP vService and is licensed separately as the TR7 AAM product (Products & Licensing).

How Does It Work?

AGS does not add a separate device or address; the following distinction is made on every request that comes to the vService (how it works):

1. If there is no session: The request goes to the vService's AGS engine instead of the Backend Service, and the user enters the login flow. If the flow ends with Allow, a session is opened; if it ends with Deny, access is denied.
2. If there is a session: The request is forwarded to the Backend Service without passing through the flow. AGS's own cookies are removed from the request; if a Backend SSO Configurations profile is bound, the credentials are added to the request.

Authentication is performed once per session, not on every request. The duration of the session and its binding to the client are determined by Session Protection Policies, and the counting of failed attempts by Account Lockout Policies.

AGS - AAM in TR7

What	Where
Enabling AGS	The AGS box in the Details list of the vService form; for multiple vServices, AGS-Enabled vService List
The login flow and vService-specific settings	The Flowchart tab of the AGS-enabled vService (with the General Settings window) and the AGS Management tab
Profiles defined device-wide	The Authentication, Protection Policies, Pages & Language and Integrations groups under Configuration Menu → AGS
Monitoring	The Dashboard, Live Stats, Sessions, Audit Logs and Engine tabs

Details of the parts: What are the basic building blocks of AGS?

Common Misconceptions

• "When AGS is enabled, users log in and reach the application." In the default flow, the output of the built-in Basic Login form is connected to the Deny step; until an Authentication Provider step is added to the flow and connected to Allow, no one reaches the Backend Service (What happens to traffic when AGS is enabled on a vService?).
• "AGS works on all vServices." It is enabled only on HTTP vServices (Which vService types does AGS work with?).
• "AGS is an identity provider." AGS is the side that connects to external IdPs; it does not provide identities to other applications (Is AGS an SSO solution; can it be used as an identity provider (IdP)?).
• "AGS takes the place of WAF." AGS verifies who sends the request; it does not inspect the content of the request (What is the difference between AGS, the WAF and Bot/DDoS protection?).

How it is done in the documentation

• AGS - AAM · What Is AGS - AAM?
• AGS - AAM · How Does It Work?
• AGS - AAM · AGS in TR7
• How to Enable AGS? · What Does Enabling AGS Mean?

Related questions

• What is the difference between the Load Balancer and AGS; where does AGS work within the Load Balancer?
• What are the basic building blocks of AGS?
• What happens to traffic when AGS is enabled on a vService?
• How much security does the Load Balancer module provide on its own; when do I need a WAF?