What is Keeper Remote Browser Isolation (RBI)?

Keeper Remote Browser Isolation (RBI) provides secure, efficient and VPN-less access to protected web-based applications directly from within the Keeper vault.

KeeperPAM protects web-based apps just like any other resource, with access control, session recording and passwordless authentication. Browsing sessions are "projected" visually from the Keeper Gateway to the end-user's vault. The sessions utilize an up-to-date Chromium browser which runs inside a virtualized container inside the Keeper Gateway.

As an additional benefit, since the web browsing session is not running on the local environment, the user is protected against the risk of malware, phishing, and other web-based threats reaching their device. Keeper RBI is available on the Web Vault and Desktop Vault Clients.

Use Cases

• Internal web apps

• Cloud security applications

• Database management interfaces

• Financial and banking websites

• Protected web browsing

How does Keeper Remote Browser Isolation Work?

When launching an RBI session, the Web and Desktop Vault Client will render a chromium browser window with a established connection to the specified web application defined on the PAM Browser record. This is done by:

1. The Vault Client communicating with the Keeper Gateway with the relevant web application info (such as URL) through a secure tunnel

2. The Keeper Gateway then establishes an http/https connection to the web application target defined on the PAM Record

3. After establishing the connection, the Keeper Gateway projects the visual Chromium UI back to the Vault user interface.

Why Use Keeper Remote Browser Isolation?

A common challenge faced by IT admins, DevOps, and security teams is protecting users from web-based threats like malware and phishing while maintaining a seamless browsing experience. Additionally, traditional security measures often require complex setups or VPNs, which can slow down productivity.

Keeper Remote Browser Isolation (RBI) addresses these challenges by:

• Providing secure, isolated web browsing sessions: Ensures that web content is executed remotely, keeping your device safe from malware, phishing, and other threats.

• Eliminating the need for VPNs: Offers secure, VPN-less access to the web, simplifying the user experience while maintaining high security.

• Streamlining configuration and management: Simplifies the setup and management of isolated browsing sessions directly from your Keeper Vault.

• Enhancing security and compliance: Centralizes control over web access, ensuring that all browsing activities comply with organizational security policies and regulations.

Keeper Remote Browser Isolation Features

• Secure, Isolated web browsing sessions - The web sessions are visually projected into the vault, but the website code is not running locally.

• Protection against web based threats like malware and phishing - With the web sessions isolated, the remote website code is sandboxed in the Keeper Gateway container.

• Session Recordings & Compliance - Browser isolation sessions can be shared, recorded and monitored for compliance and security reasons

• Credential Autofill - Keeper's remote browser isolation protocol can automatically inject credentials, submit forms and control the target web application without ever sending the credentials to the user's device.

To get started with Remote Browser Isolation, proceed to the next section.

Overview

In this guide, you will learn how to setup Remote Browser Isolation (RBI) in your Keeper Vault. RBI works from both Web Vault and Desktop App.

An active license is required in order to use the features available with KeeperPAM. This license is available for both business and enterprise customers.

• KeeperPAM Homepage

• Request a Demo

• Contact Support

Prerequisites

Prior to configuring RBI, make sure to have the following:

Remote Browser Isolation Enforcement Policies

Enforcement policies for KeeperPAM are managed in the Keeper Admin Console under Admin > Roles > Enforcement Policies > Privileged Access Manager.

The following Enforcement Policies affect user's permissions to use Remote Browser Isolation and need to be enabled:

ALLOW_CONFIGURE_RBI

ALLOW_LAUNCH_RBI

ALLOW_VIEW_RBI_RECORDINGS

The above enforcement policies can also be enabled on the Keeper Commander CLI using the enterprise-role command:

enterprise-role "My Role" --enforcement "ALLOW_CONFIGURE_RBI":true
enterprise-role "My Role" --enforcement "ALLOW_LAUNCH_RBI":true
enterprise-role "My Role" --enforcement "ALLOW_VIEW_RBI_RECORDINGS":true

Enforcement Policy Use Cases

If a user should only have access to launch RBI sessions and not configuring RBI settings, then only "Can launch remote browsing" policy should be enabled for the user.

In addition to launching RBI sessions, If a user should also have access to configure RBI settings, then "Can configure remote browsing settings" and "Can launch remote browsing" policies should be enabled for the user.

To allow users to view RBI session recordings, then "Can configure remote browsing settings" policy should be enabled for the user.

Session Recordings

Launched RBI sessions can also be recorded. These recordings are available on the PAM Browser record types and can be played back on your Vault. For more details on session recording and playback, visit this page.

Installing the Keeper Gateway

The Keeper Gateway is a hosted agentless service that is installed on the customer's network to enabled zero-trust access to target infrastructure. Typically this service is installed on a Linux or Docker environment in each of the networks that requires access.

For more details on installing and setting up your gateway, visit this page.

PAM Configuration

The PAM Configuration contains essential information of your target infrastructure, settings and Keeper Gateway. Setting up a PAM Configuration for your infrastructure is required. For more information on creating and configuring the PAM Configuration, visit this page.

PAM Remote Browser

When launching an RBI session, the Web and Desktop Vault Client will render a chromium browser window with a established connection to the specified URL defined on the PAM Browser record. For more information on how to setting up the PAM Browser Record, visit this page.

PAM Settings - Remote Browser Isolation

Accessing RBI Settings

After creating a PAM Browser Settings with the target URL, navigate to the PAM Settings by:

1. Editing the PAM Browser Record

2. Clicking on "Set Up" in the PAM Settings section

Configuring RBI Settings

After opening up the PAM Settings screen. The following table lists all the configurable fields for RBI:

Session Recordings - RBI

For this protocol, graphical data, including timing information, is recorded. For more details on the recordings and how to access them, see the Session Recording & Playback docs.

Overview

This guide will go over the following PAM settings section for the PAM Browser Record:

• URL Patterns

• Resource URL Patterns

URL Patterns & Resource URL Patterns

The format of the URL patterns accepted by the “Allowed URL Patterns” and “Allowed Resource URL Patterns” parameters is identical to any URL and dictates exactly which URLs are allowed to be used. They are enforced according to the following criteria:

• Any aspect of the URL that is omitted from the pattern is ignored (not enforced as a requirement), except that standard port numbers are considered to have been specified if a scheme is specified.

• A *. wildcard prefix may be used for domain names to indicate "any subdomain of a particular domain".

• A * wildcard may be used in place of a path to more visibly and explicitly note that any value is allowed.

• A * wildcard may be used at the end of a path to indicate that any subpath of that path is allowed.

• A * wildcard may be used in place of a port number to indicate that any port is allowed.

For example:

In the next section, we'll cover the autofill capabilities.

Overview

KeeperPAM can automatically fill credentials into the target remote browser isolation session. Credentials are never exposed to the user - the Keeper Gateway performs the filling inside of the Chromium session, and the session is visually projected into the user's vault.

An example of an RBI record is below. This is an Amazon AWS login that will autofill a credential.

Eligible Credentials

In order for the Keeper Gateway to autofill the credentials, the record must be added to a Shared Folder which is associated to the gateway.

In this example, the "craigdemouser" AWS identity is saved to a shared folder which is controlled by the Keeper Gateway:

The Shared Folder is shared to the Application holding the Keeper Gateway:

The Application is associated to the Keeper Gateway. This gives the Gateway the ability to access and decrypt any shared credentials.

To set up Autofill, edit the autofill settings by clicking on "Edit" in the PAM Settings section of the record.

The configuration of Remote Browser Isolation provides the ability to select which credential is filled.

When launching the session, the username and password for the AWS Console is autofilled within the isolated browser session. The credentials are not exposed to the user and the form fields cannot be inspected.

Autofill Targets

The autofill rules used by KCM are a JSON/YAML array of objects, where each object specifies at least the following property:

• page - The URL pattern of the page that the autofill rule applies to. The patterns accepted here are identical to the patterns accepted by the navigation/resource rules.

and one or more of the following properties:

• username-field - A CSS selector that matches the field that should receive the filled username. The Keeper Gateway will inject the value of the username field from the Keeper record.

• password-field - A CSS selector that matches the field that should receive the filled password. The value filled will be the value of the password parameter for the connection.

• totp-code-field - A CSS selector that matches the field that should receive the filled TOTP code. The value filled will be the value of the totp parameter for the connection.

• submit - A CSS selector for an element that should be clicked once all applicable username/password fields have been populated. This should only be specified if necessary (ie: if the login page in question does not actually use a proper HTML <form>). When omitted, KCM will attempt to submit the login form as if the user pressed "Enter".

• cannot-submit - A CSS selector to tell KCM not to automatically submit the form as long as any matching element is present

Basic Example: A single page web application with a Login and Password field:

Copy

- page: "http://172.31.8.134:8080/login"
  username-field: "input[name='j_username']"
  password-field: "input[name='j_password']"

Some login flows will require multiple rules. For example, the Microsoft Azure Portal login flow would be an example of this.

Here's a YAML example of the autofill rules that would be necessary for Microsoft Azure:

Copy

- page: "login.microsoftonline.com"
  username-field: "input[autocomplete='username']"

- page: "login.live.com"
  password-field: "input[autocomplete='current-password']"

Here's the equivalent, formatted as JSON:

Copy

[
    {
        "page": "login.microsoftonline.com",
        "username-field": "input[autocomplete='username']"
    },
    {
        "page": "login.live.com",
        "password-field": "input[autocomplete='current-password']"
    }
]

A common example where you would not want Keeper automatically submitting is when there's a captcha on the page. An example of this is below:

- page: "https://dash.cloudflare.com/login"
  username-field: "input[id='email']"
  password-field: "input[id='password']"
  cannot-submit: "div[data-testid=challenge-widget-container]"

For unusually complex pages where CSS is not sufficient, XPath expressions may be used instead. Any such XPath expression must be constructed with a leading /.

Field Identification

Remote Browser Isolation will fill credentials based on the specific field elements defined in the JSON or YAML code. Form field selectors can be found by inspecting the content of the page and locating the specific field element.

1. Inspect the Page: Open the developer tools by right-clicking on the webpage and selecting "Inspect."

2. Select the Field: Use the element selector tool to click on the form field you want to identify.

3. Read the Attributes: Look at the highlighted HTML code to find attributes like autocomplete, type, name, id, or other identifiers.

Example 1: Using autocomplete

• HTML Code: <input type="password" autocomplete="current-password" ...>

• Explanation: The password field can be identified by the autocomplete attribute set to current-password.

Example 2: Using type

• HTML Code: <input type="password" ...>

• Explanation: The password field can be identified by the type attribute set to password.

Example 3: Using name

• HTML Code: <input type="password" name="some_name_xyz" ...>

• Explanation: The password field can be identified by the name attribute set to some_name_xyz.

Example 4: Using id

• HTML Code: <input type="password" id="some_id_1234" ...>

• Explanation: The password field can be identified by the id attribute set to some_id_1234.

Testing Field Identification

From your Chrome browser, open the developer tools and visit the Console tab.

To test the form field idenfication, use the document.querySelector() javascript command.

For example, type the below and press <enter>:

Copy

document.querySelector("input[type='password']")

If the field is found, the DOM element will be displayed. Otherwise, an error will be displayed.