ags

The ags command branch manages TR7's AGS - AAM (Application Access Management) resources from the command line: the access gateways, the authentication servers and providers, the local user databases, the login forms, the MFA configurations, the security policies and the integrations. Its panel equivalent is the AGS - AAM section; every command here does the work that a screen in that section does.

12 Resources

the commands under ags

Two of them (profiles, security) are only groupers; the record management is in their sub-commands.

5 Commands

list · show · add · update · delete

The same five commands on every resource; the learned pattern repeats throughout the branch.

Narrows on type selection

type · method · gatewayMode

The moment the type field is selected only the fields of that type are asked for; the rest is hidden.

Load Balancer permission

the permission area of the ags branch

The view permission is required for reading and the modify permission for writing.

Command Map

Command	What it manages	Panel screen
ags gateway	The access gateway: the definition of the flow (form → identity → MFA → decision)	AGS Management
ags authentication-server	A directory or service connection (LDAP, RADIUS, HTTP…)	Authentication Servers
ags authentication-provider	The authentication method (9 provider types)	Authentication Providers
ags local-database	The local user database and the password policy	Local Databases
ags local-user	The user accounts in the local database	Users tab
ags forms	The login forms and the form fields	Login Forms
ags mfas	The MFA configurations (TOTP, email/SMS OTP, HTTP OTP)	Multi-Factor Authentication
ags backend-sso-configs	Passing the identity to the backend service	Backend SSO Configurations
ags notifications	The notification profiles (the threshold and alarm settings)	Notification Profiles
ags log-forwarders	Exporting the access logs	Log Forwarding
ags profiles → page-templates · dictionaries	The page templates and the multi-language dictionaries	Page Templates · Dictionaries
ags security → lockout-policies · session-protection-policies · rate-limit-policies · captcha-providers	The lockout, session protection, bot protection and CAPTCHA policies	Protection Policies

One command name does not match the screen name

ags security rate-limit-policies manages the records that appear in the panel under the name Bot Protection Policies. The command name and the screen name are different; the rate limiting is a part of these policies.

The Same Five Commands on Every Resource

When the commands of one resource are learned, the others are known too. The pattern is the same on every resource:

TR7 WEB-CLI · the five command pattern

admin@TR7LBWAF01> ags authentication-server list # list all of them

admin@TR7LBWAF01> ags authentication-server show <id> # show one

admin@TR7LBWAF01> ags authentication-server add <fields> # new record

admin@TR7LBWAF01> ags authentication-server update id <id> <fields> # change

admin@TR7LBWAF01> ags authentication-server delete <id> # delete

admin@TR7LBWAF01>  

How the identity is written changes according to the command; both are selected from the record names with Tab:

Command	How the identity is written
show · delete	Right after the command, without writing the field name: show <id>
update	With the id field: update id <id>; without the identity being given the other fields are not listed

The Field Writing Rules

These rules are valid throughout the ags branch:

Rule	How it is written
Required field	It is written without a prefix and is asked for in order: add name corporate-ldap protocol ldap
Optional field	It takes the -- prefix: --connectionTimeout 30
List field	Every item with its own index: --hosts.0.host 10.0.0.30 --hosts.1.host 10.0.0.31
Nested field	With a dot: --addr.ip, --title.text
Password field	It is not written on the command line; it is asked for on a separate line, without appearing on the screen
Type field	After fields such as type, method, gatewayMode are selected, only the fields of that type are asked for
Emptying a field	Only during update: --field.delete

Seeing the next field

The required fields are asked for one by one: without one being written the next is not listed. To see what can be written at the point reached, Tab is used, and for the annotated list a ? is written at the end of the line and Enter is used. To read what a command does without running it, --info is added.

Setting Up an Access Flow from Scratch

The gateway refers to the pieces of the flow by their identities; for this reason the pieces are created first and the gateway is edited last.

Step 1 Define the identity source

The directory connection is opened, then the provider that uses this connection is created. In the provider command the first field written is the type; until the type is selected not even the name of the record is asked for. When the type is written only the fields of that type open.

ags authentication-server add name corporate-ldap protocol ldap --hosts.0.host 10.0.0.30 --hosts.0.port 389
ags authentication-provider add type ldap name corporate-login authServerId <server-id> …

If there is no external directory, instead of this step a database is opened with ags local-database and then the accounts with ags local-user.

Step 2 Create the login form

The form is created with only a name; the fields (username, password, submit button) are added afterwards with indexed fields.

ags forms add name login-form

Step 3 Add the second factor if needed

When the method is selected the required fields of that method are asked for: for TOTP the organization name to be displayed, for OTP the channel, for HTTP OTP the address and the method.

ags mfas add name totp-verification method totp totpIssuerName Company

Step 4 Prepare the security policies

The lockout, session protection, bot protection and CAPTCHA policies are separate records and are bound to the gateway by their identities.

ags security lockout-policies list

Step 5 Combine in the gateway

The gateway record is formed by itself for every vService on which AGS is enabled and is referred to by the vService name. For this reason, when setting up the flow, instead of adding a new record the existing record is edited: first the list is taken, then the flow steps (the actions) are written with indexed fields.

ags gateway list
ags gateway update id <vService-id> --actions.0.actionType agsForms --actions.0.actionProfileId <form-id>

If AGS is not enabled on the vService

The gateway record is listed only for the vServices on which AGS is enabled. Taking a vService into the AGS scope is done from the panel; see AGS-Enabled vService List.

Permission

The ags commands are bound to the Load Balancer permission area: the view permission in this area is required for seeing and reading the branch, and the modify permission for adding, changing or deleting a record. The superAdmin role runs all the commands, the readOnly role uses only the list and show commands. A command without permission is not run and a Permission denied. warning is returned (on a user whose interface language is Turkish, Yetkiniz bulunmamaktadır.). For the details the API Commands page can be looked at.