Skip to content

WEB HTTP Sessions

Overview

WEB HTTP Sessions provide browser-based privileged access through native HTTP and HTTPS session proxying directly within the PAM platform. Unlike traditional approaches that rely on Remote Desktop Services (RDS) infrastructure or dedicated jump hosts, WEB HTTP Sessions leverage a headless browser running on PAM nodes to establish, isolate, and manage connections to target web applications.

This architecture enables organizations to deliver secure access to administrative and business-critical web portals while maintaining centralized control, auditing, and credential protection. By brokering all web traffic through the PAM platform, privileged interactions remain isolated from endpoint devices, supporting zero-trust access models without additional client-side software or browser extensions.

Architecture and Operation

When a user initiates a WEB HTTP Session, the PAM platform launches an isolated headless browser instance on a PAM node. The headless browser establishes the connection to the target web application and manages the entire HTTP or HTTPS session on behalf of the user.

The PAM platform retrieves the required credentials from the secure vault and injects them directly into the target web portal's authentication process. Credentials are never exposed to the user's workstation or browser.

The remote browser session is continuously rendered and streamed to the user's local browser through a remote gateway. User interactions, including keyboard and mouse input, are transmitted back to the remote browser instance in real time, creating a seamless and responsive user experience.

As an intermediary between the user and the target application, the PAM platform provides:

  • Session isolation
  • Credential protection
  • Centralized auditing and recording
  • Granular access policy enforcement
  • Real-time session control and termination capabilities

This model allows organizations to secure browser-based administrative access while reducing infrastructure complexity compared to traditional RDS-based approaches.

Additional Information

For a comprehensive overview of WEB HTTP Sessions, including architecture, security benefits, supported use cases, and deployment considerations, see the WEB HTTP Sessions FAQ.

Configuration and Usage

Create a Web Portal Asset

To configure a WEB HTTP Session, first create a new Asset using the Web Portal asset type.

  1. Create a new asset and select Web Portal as the asset type.
  2. Populate the required asset fields, including:
    • URL
    • User
    • Password
  3. If the target site uses HTTPS and is protected by a publicly trusted SSL/TLS certificate, enable the Trust Certificate option.
  4. Save the asset.

Assign Permissions and Access Profiles

After creating the asset, assign the appropriate Permission and Access Profile objects to the asset. This ensures authorized users can locate the asset and initiate WEB HTTP Sessions.

Launch a WEB HTTP Session

To start a WEB HTTP Session:

  1. Navigate to the Web Portal asset you want to access.
  2. Initiate a session using one of the following methods:
    • From the Asset List page, click Quick Access.
    • From the View Asset page, click Access.
    • From the Container View, select Access from the asset's Actions menu.
  3. When the Session Launcher appears, configure any required session parameters.
  4. If prompted, enter your multi-factor authentication (MFA) token.
  5. Click Access to launch the session.

Depending on the options selected in the Session Launcher, the session will open in either a new browser tab or a new browser window. During session initialization, 12Port automatically retrieves the stored credentials and populates the required authentication fields. Upon successful authentication, you will be logged in to the target web portal and can interact with it normally.

End the Session

When you have completed your work, log out of the target web application using its native Sign Out or Log Out functionality.

After logging out, close the browser tab or window used for the session.

Troubleshooting

Specify Login Form Fields for Automated Credential Injection

In some cases, the 12Port PAM platform may be unable to automatically identify the username and password fields on a target web portal's login page. This can occur when the application uses non-standard field names or custom authentication forms.

To explicitly define which fields should receive credential values, configure the Page Schema field on the WEB Portal asset type. This field is hidden by default and controls how credentials are injected into the login form.

The Page Schema value is composed of up to four slash-separated sections:

user fields/password fields/ignored field types/action types

Each section may contain one or more comma-separated field names or field types.

How Page Schema Field Matching Works

When the password filler component (either a WEB HTTPS session or the browser extension) processes a login page, it evaluates all HTML input elements on the form and applies a series of filtering and matching rules to determine which fields should receive credential values.

Ignored Field Types

Before attempting to populate credentials, the filler excludes any input elements whose type attribute matches a configured ignored field type.

By default, the following input types are ignored:

hidden, submit, button, checkbox, color, date, datetime-local,
file, image, month, number, radio, range, reset, search,
tel, time, url, week

Additional ignored field types can be specified in the third section of the Page Schema value.

This filtering prevents credentials from being inserted into non-authentication controls, such as buttons or other unrelated form elements that may use names similar to credential fields.

Username and Password Field Detection

After filtering, the filler identifies candidate username and password fields by evaluating each element's name and id attributes.

Field matching is performed against:

  • Built-in default username field identifiers
  • Built-in default password field identifiers
  • Any custom field names defined in the first and second sections of the Page Schema

Default username field identifiers include:

Username
User name
email
user
login
identifier
UsernamePassword_username_input

Default password field identifiers include:

Password
UsernamePassword_password_input

If a field's name or id matches one of the configured username or password identifiers, the filler populates the field with the corresponding credential value.

Overriding or Extending Default Field Identifiers

By default, specifying unique username or password field names in the Page Schema replaces the platform's built-in field identifiers for that section. Only the field names explicitly configured in the Page Schema are used when matching login form fields.

To retain the built-in identifiers while adding custom field names, prefix the corresponding Page Schema section with a plus sign (+).

When a section begins with +, the platform combines the built-in field identifiers with the custom identifiers specified in that section.

For example:

username,Editbox1/+password,Editbox2

In this example:

  • The username field identifiers are overridden. Only username and Editbox1 are considered valid username fields.
  • The password field identifiers are extended. The platform matches the built-in password identifiers (Password and UsernamePassword_password_input) in addition to the custom fields password and Editbox2.

Without the + prefix, the Page Schema section completely replaces the corresponding built-in identifier list. With the + prefix, the configured identifiers are appended to the built-in defaults instead of replacing them.

Action Execution

After credentials have been populated, the filler can optionally execute an action, such as submitting the login form.

To perform an action, the filler searches for an HTML element of type:

  • a
  • button
  • input

The element is matched using its:

  • name
  • id
  • type
  • jsname

attributes.

The value specified in the fourth section of the Page Schema is used as the action identifier. In addition, submit is treated as a default action type.

In most login forms, the action element is a button with type="submit". However, some applications use alternative elements, such as an anchor (<a>) element with a name such as login. In these cases, the action can be explicitly specified in the Page Schema configuration.

Examples

Example 1

usr/pwd,pwd0

This example instructs the platform to populate the username field named usr and the password fields named pwd and pwd0.

Example 2

usr/pwd,pwd0//submit

This example performs the same credential injection and additionally invokes the submit action after the fields have been populated.

Finding Form Field Names

If credential autofill is not functioning as expected, inspect the target website's login form to identify the HTML form field names used for the username and password inputs, then configure the Page Schema field accordingly on the associated WEB Portal asset.

To identify the correct field names, open the login page in your browser, right-click the username or password field, and select Inspect. In the HTML, locate the corresponding <input> element and note its name attribute value. Use these name attribute values in the Page Schema configuration. For example, if the username field is <input name="usr"> and the password field is <input name="pwd">, configure the Page Schema as usr/pwd.