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 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.

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.