Smarter by Design.Simpler for Business
Standalone Application
What Is Standalone Application?
In the Standalone Application mode the vService passes the requests that come to the application behind it through its own login flow: the identity of the visitor is verified with the flow defined on the Flowchart tab of this vService and the session opened is valid only in this vService. The session of another vService is not accepted directly in this mode.
When AGS is enabled for the first time in the vService, the configuration is created with this mode; Cookie Domain comes empty and Cookie Name Prefix comes Automatic. Since the configuration is not deleted when AGS is turned off and on again, the previous mode and flow come back.
This mode is used in order to protect a single application with its own login page. If the users are wanted to access more than one application with a single login, the vService that opens the session is configured in the Portal mode, and the applications that will accept the portal session in the Portal Application mode.
Default
Gateway Mode
When AGS is enabled for the first time, the vService starts with this mode
3 Fields
Gateway Mode Section
Gateway Mode · Cookie Domain · Cookie Name Prefix
Start
The Entry of the Flow
The visitor enters the flow from the step to which the Start box is connected
1 vService
Session Scope
Only the session issued by this vService is accepted
AGS_
Default Prefix
In the Automatic position the cookie names are created with the AGS_ prefix
403
The Session of Another vService
A session of another vService that comes with a cookie of the same name is refused
How Does Standalone Application Work?
The request that comes to the vService is first evaluated in the traffic engine. If the request does not carry a valid authenticated session and matches the AGS Activation Condition condition, it is directed to the AGS engine; the visitor enters the flow from the step to which the Start box is connected and the login, verification and auxiliary pages are served under the AGS Root Path. The requests that do not match the condition (except the ones under the AGS Root Path) are forwarded to the Backend Service with the actions of the vService without visiting the AGS engine.
The requests that come after the flow is completed with Allow do not visit the AGS engine: they are forwarded to the Backend Service with the actions of the vService, and if no action matches, they go to the default Backend Service of the vService. This behavior is different from the Portal mode: in the Portal mode the requests with a session that do not match an action go to the AGS engine, to the portal page. The AGS cookies of the vService are stripped from the request that goes to the Backend Service.
The session is accepted only with the session cookie issued by this vService. To the requests that come with a session cookie that carries the same name and is valid but has been issued by another vService, including the login pages and the requests that do not match the AGS Activation Condition condition, HTTP 403 is returned with the text Session cookie issuer not trusted by this gateway. The direct acceptance of the portal session is not established in this mode; the portal tunnel and the portal session transfer work only in the Portal and Portal Application modes.
The session protection, bot protection, lockout and Backend SSO settings are applied in this mode in the same manner as in the other modes. The steps of the flow, the step addresses and the resolving of the AGS variables are explained on the Flowchart page.
The Comparison of the Modes
| Feature | Standalone Application | Portal | Portal Application |
|---|---|---|---|
| The place where the session is opened | The flow of this vService | The flow of this vService | The trusted portal |
| The Start box | Present | Present | Absent |
| The session accepted | Only that of this vService | Only that of this vService | That of this vService and of the trusted portals |
| A request with a session that does not match an action | The default Backend Service | The AGS engine (the portal page) | The default Backend Service |
| The additional fields in the Gateway Mode section | None | Portal URL, Private Tunnel Domain, Portal Applications | Trusted Portals |
Accessing the Standalone Application Mode
- Left Monitor Panel is opened.
- AGS-Enabled vServices is selected from the category tabs at the top left.
- The vServices defined on TR7 with AGS access control enabled are listed.
- The vService to be monitored is clicked; the screen opens with the Dashboard tab that carries the vService's name.
- On the screen that opens, the Flowchart tab is clicked.
- The switch at the top left is taken to the Edit Mode position.
- The General Settings button on the toolbar is clicked; in the Gateway Mode section of the window that opens, Standalone Application is selected in the Gateway Mode field.
The Gateway Mode field is also located in the Edit / Scope & identity window opened with the Edit link of the mode section on the AGS Management tab, and Cookie Domain and Cookie Name Prefix in the Edit / Session window of the Session section; in these windows the change is saved directly with Accept. The transition to the Portal Application mode is made from the General Settings window on the Flowchart tab.
The Gateway Mode Section
While Standalone Application is selected, three fields are displayed in the Gateway Mode section of the General Settings window. The fields specific to the portal modes are hidden in this mode.
The Gateway Mode Section
INFO
Gateway Mode Mandatory Default: Standalone Application
The working mode of AGS is selected. The options in order are Standalone Application, Portal and Portal Application; there is no option that can be left empty. When the mode is changed, the fields specific to the mode appear or disappear in the window immediately (The Mode Change).
INFO
Cookie Domain
The domain name for which the session cookie will be valid is entered (the placeholder is company.com). The value is entered in the domain name form; a dot at the beginning is accepted (e.g. .company.com). If the same vService is published with more than one subdomain (e.g. app.company.com and www.company.com), a single session is used at these addresses by entering the upper domain name. When it is left empty, the cookie is valid only for the address the request comes to.
The value contains only English letters, digits, - and .; the domain names with Turkish characters are entered in the punycode form. The format is not checked in the window; an invalid value is reported during Save (during Accept in the AGS Management Edit / Session window) with an error text that starts with Value does not match required pattern.
INFO
Cookie Name Prefix Default: Automatic
The prefix to be added to the names of the AGS cookies is determined. While the switch is in the Automatic position, the cookie names are created with the AGS_ prefix (e.g. AGS_SESSION). When the switch is taken to the Choose position, a text box opens next to it; a prefix consisting only of English letters, digits, _ and - characters and between 1 and 32 characters is entered. When the switch is turned off and on again, the last value entered comes back to the box.
The prefix is written at the beginning of the cookie name without a separator being added: when app1_ is entered the session cookie takes the name app1_SESSION, and when app1 is entered app1SESSION. If the box is left empty, Automatic is used in the record and when the window is opened again the switch comes in the Automatic position. The length and character rules are not checked in the window; a prefix that does not obey the rule is reported with an error window during Save (during Accept in the AGS Management Edit / Session window).
The vServices that share the session cookie
If the session cookie of a vService reaches the address of another vService on the same TR7 as well (e.g. if two vServices are published under the same Cookie Domain or on different ports of the same domain name) and if the two vServices use the same prefix (e.g. if both are Automatic), the other vService, which accepts only its own session in this mode, returns HTTP 403 with the text Session cookie issuer not trusted by this gateway. to all the requests, including the login pages and the requests outside the AGS Activation Condition. When a different Cookie Name Prefix is given to each of the vServices whose cookies can reach each other with Choose, the cookies are stored with separate names and the vServices work independently of each other. No warning is shown for this conflict during the save.
INFO
The changes made in the window are transferred to the diagram with Accept and are saved with Save on the toolbar (The General Settings Window).
The Places Where the Mode Is Displayed
| Place | What is displayed |
|---|---|
| Flowchart | The STANDALONE APPLICATION badge next to the Start box. |
| AGS-Enabled vService List | Standalone application in the Gateway Mode column. |
| The Dashboard and AGS Management preview drawing | Standalone application under the label of the AGS strip; Standalone application in the title of the Gate Node information window, and This vService fronts a single application; users sign in here directly in its first row. |
| The AGS Management mode section | The title Standalone application, the subtitle This vService fronts a single application; users sign in here directly. In the section there is no Portal address row and no Applications chip; the Portal & Applications section is not displayed. |
| The AGS Management Session section | If Cookie Domain is filled, The session cookie is shared across <domain>, and if it is empty, The session cookie is valid for this address only. If a prefix is defined, the row Cookie name prefix <prefix> is added; in the Automatic position the prefix row is not displayed. |
The mode is not shown on the AGS-Enabled vServices tab of the Left Monitor Panel.
The Mode Change
When Gateway Mode is changed, the Cookie Domain, Cookie Name Prefix, the policies and the Backend SSO Config values are preserved in every mode. No confirmation is asked for the change. In order to return before saving on the Flowchart, the unsaved changes are discarded by passing to the View Mode; in the AGS Management Edit / Scope & identity window the change is saved directly with Accept.
| Transition | Result |
|---|---|
| Standalone Application → Portal | The Portal URL, Private Tunnel Domain and Portal Applications fields appear; until the mandatory fields are filled, Accept stays inactive. The flow and the Start connection are preserved. |
| Standalone Application → Portal Application | The Trusted Portals field appears. With Accept the Start box is removed from the diagram and with Save the Start connection is deleted from the record; the steps of the flow are not deleted. |
| Portal → Standalone Application | The Portal URL, Private Tunnel Domain and Portal Applications values are removed from the diagram with Accept and are deleted from the record with Save. The Portal Application vServices that keep this vService in their Trusted Portals list are not updated by themselves; the list of these vServices is edited separately. |
| Portal Application → Standalone Application | The Trusted Portals value is removed from the diagram with Accept and is deleted from the record with Save. If the record has been saved in the Portal Application mode, the Start box comes unconnected; it is connected to the first step of the flow before saving. |
Its Relation with the Portal
- A vService in this mode can be selected as an Application vService in the Portal Applications list of a vService in the Portal mode; the list contains all the HTTP vServices independently of the mode.
- As long as the selected vService stays in the Standalone Application mode, it does not accept the session of the portal: if the session cookie of the portal reaches this vService and the prefixes are the same, the requests are refused with 403; otherwise the vService opens its own login flow and the visitor who has no session is not redirected to the portal. In order for the portal session to be accepted, the Gateway Mode value of the vService is made Portal Application and the portal is selected in the Trusted Portals list.
- Only the vServices in the Portal mode are displayed in the Trusted Portals list; a vService in this mode cannot be selected as a trusted portal by another vService.
- When a provider step of the Portal type on the Authentication Providers screen is added to the flow, the authentication is left to the vService in the Portal mode; when the flow is completed, the session is again opened by this vService.
Scope and Limits
INFO
- The session is specific to the vService. In this mode the session of another vService is not accepted directly; the acceptance of the portal session is established with the Portal and Portal Application modes.
- It is the default mode and it is preserved. When AGS is enabled for the first time, the vService starts with this mode; when AGS is turned off and on, the mode and the flow come back from the record.
- The security settings are independent of the mode. The session protection, bot protection, lockout and Backend SSO settings work in this mode in the same way as in the other modes.
- The cookie fields are checked during the save. The format of Cookie Domain together with the length and character rules of Cookie Name Prefix are checked not in the General Settings window but during the save.
- The vServices that share the session cookie use a separate prefix. The vServices that work with the same prefix and whose cookies reach each other refuse each other's session with 403; no warning is shown for this conflict during the save.
