PAM › User Guide
Adding Applications
Register web applications so users can sign in through GAccess without ever seeing the underlying credentials
Adding Applications
Overview
An application in GAccess is a web application that users sign in to through the platform. GAccess handles the login automatically using a stored credential, so users get into the app without ever seeing the account password. Sessions can run through the browser extension or, for stronger isolation, inside a remote browser on a Gateway.
You add an application from the Applications section by clicking Add Application.
Basic information
| Field | Description |
|---|---|
| Application Name | A unique, friendly name for the application. Required. |
| Login URL | The page where the application's sign-in form lives (for example, https://app.example.com/login). Required. |
| Description | Free-text notes about the application. Optional. |
| Tags | Labels for searching and organizing applications. Type a tag and press Tab or Enter to add it. Optional. |
Remote Browser Isolation
You can optionally route this application through a Gateway to run it inside a secure remote browser ("Remote Browser Isolation"). Choose a gateway from the dropdown, or leave it set to None to use the Chrome extension instead. When a gateway is selected, connections open an isolated browser on the gateway rather than running in the user's own browser.
Authentication method
When you are not using Remote Browser Isolation, choose how GAccess signs users in:
| Method | How it works |
|---|---|
| Legacy (DOM) | The browser extension fills the login form fields directly. Most compatible, and a good choice for apps that have trouble with OAuth redirect loops. |
| Cookie Auth | A headless browser on the GAccess server performs the login and injects the resulting session cookies into the user's browser. |
| Token / localStorage | A headless login extracts tokens (such as a JWT) from the application's storage and uses them to establish the session. |
Login steps
Most applications log in with a simple username and password form, and you can leave the login steps empty to let GAccess detect the fields automatically. For applications with a custom flow — such as a "Next" button between the username and password screens, or an extra field like an account ID — you can define one or more login steps that run in order.
Each step describes part of the form:
| Field | Description |
|---|---|
| Form Selector | An optional CSS selector identifying the form to act on. |
| Fields | One or more inputs to fill. Each field has a CSS selector and a type: Username, Password, MFA Code, or Static (a fixed value you supply, such as a company domain). |
| Submit Selector | The button that submits the step (for example, the Next or Sign In button). |
| Wait For Element | An element to wait for before moving to the next step — useful for multi-screen logins. |
| Fallback delay | A short pause before proceeding, used if no wait element is set. |
Success criteria
You can optionally tell GAccess how to confirm the login worked — by checking for a CSS selector, a URL fragment, a cookie, or a localStorage key. If you leave this blank, login is assumed successful once all steps complete.
Assigning credentials
In the Credentials section you choose which stored credential GAccess uses to sign in to this application. Search by name, username, or tag, filter by type, and tick the credential to use. Selected credentials appear in a summary list and can be removed before saving.
Session controls
These settings govern the user's session with the application:
| Setting | Effect |
|---|---|
| Record video session | The session is recorded for audit. |
| Disable Copy From Session | Prevents copying content out of the session. |
| Disable Paste In Session | Prevents pasting content into the session. |
| Session Timeout | The maximum duration a session can run before it is closed automatically. |
When Remote Browser Isolation is used, additional controls are available — such as restricting which domains the remote browser may visit, blocking downloads, blocking the right-click menu, and hiding the address bar.
Permissions
Access to each application is controlled by policies attached to that application, by ownership, and by roles. From an application's detail page you can add a policy that targets a user or a group and grants one or more of the following permissions:
| Permission | What it allows |
|---|---|
| Read | The application appears in the Applications list and its details can be viewed. |
| Connect | The user can open a session to the application. To connect successfully they must also have Connect on the credential used for the session. |
| Manage | Full control: edit and delete the application. Includes Read and Connect. |
How permissions are determined
- Creating a new application requires the Create permission, which is granted through a Role, not through a per-application policy.
- The owner — the person who created the application — automatically has full (Manage) control of it.
- Permissions are additive: a user receives the combined total of every policy that applies to them, whether granted directly or through one of their groups, plus anything they get from ownership.
- Policies can be time-bound (a start and end date) and scheduled (specific days of the week and time ranges in a chosen timezone). Access applies only within those windows.