What are the basic building blocks of AGS?

Short answer

AGS consists of three parts: the login flow specific to each vService (Flowchart) and its settings (General Settings); profiles that are defined once device-wide and used on many vServices; and the AGS engine that runs separately for each AGS-enabled vService. The profiles are collected in four groups under Configuration Menu → AGS: Authentication, Protection Policies, Pages & Language and Integrations. The flow steps and the settings select from these profiles; when a profile is changed, all the vServices that use it are affected.

How Does It Work?

1. Flow: A user without a session goes through the steps in the Flowchart; each step runs a profile (a form step runs a Login Forms profile, a provider step an Authentication Providers profile, an MFA step a Multi-Factor Authentication (MFA) profile).
2. Protection: Failed attempts are counted with lockout policies, and bot policies respond to automated traffic; the session that is opened when the flow ends with Allow is limited by the session protection policy.
3. Propagation and logging: According to the Backend SSO profile, the identity is added to the requests that have a session; events are written to the audit log and forwarded to the selected targets.

AGS Building Blocks in TR7

Building block	What it does	Scope
Flowchart, General Settings, AGS Management	The login flow; AGS Activation Condition, AGS Root Path, Gateway Mode, the selected policies, the appearance and Backend SSO	vService
AGS engine	Serves the login pages and runs the flow; it is created automatically when AGS is enabled	vService
Authentication Providers, Authentication Servers, Local Databases, Multi-Factor Authentication (MFA)	Where and with which protocol the identity is verified, the LDAP / RADIUS / HTTP server records, the accounts kept on TR7, the second factor	Device-wide
Session Protection Policies, Account Lockout Policies, Bot Protection Policies, CAPTCHA Providers	Session durations and binding to the client, failed attempts and lockout, the automated traffic directed at AGS, the CAPTCHA service	Device-wide
Login Forms, Page Templates, Dictionaries (Multilingual)	The fields of the login form, the appearance of the pages, the languages of the texts	Device-wide
Backend SSO Configurations, Notification Profiles, Log Forwarding	Propagation of the identity to the Backend Service, event notification, audit log forwarding	Device-wide

On the AGS-enabled vService screen, next to the Dashboard tab that carries the name of the vService, there are the AGS Management, Flowchart, Live Stats, Sessions, Lockout, TOTP, Audit Logs, Bot Protection and Engine tabs (tabs); the Bot Protection tab appears only while a bot policy that keeps a count or block table (one whose trigger is Requests or Auth Failures, or whose action is Block; e.g. the default Standard Rate Limiting) is selected.

Common Misconceptions

• "A separate provider and policy are defined for each vService." Profiles are device-wide; the same LDAP provider or lockout policy is selected on many vServices.
• "Authentication Providers and Authentication Servers are the same screen." The server record holds the connection settings, while the provider holds how the identity is verified (What is the difference between an Authentication Provider and an authentication server?).
• "The AGS engine is a single service on the device." Each AGS-enabled vService runs its own engine; its status is monitored on the Engine tab of the vService.

How it is done in the documentation

• AGS - AAM · Core Building Blocks
• AGS - AAM · Binding Profiles to a vService
• AGS-Enabled vServices · Tabs
• Configuration Menu · AGS

Related questions

• What is AGS - AAM and what does it do?
• What is the Flowchart; which step types does an AGS flow consist of?
• What is an Authentication Provider; which provider types does AGS support?
• Which monitoring screens does AGS have; what does each one show?