Remote Browser Isolation

Advanced configuration of HTTP/HTTPS Remote Browser Isolation connection type

This feature has been published live with Keeper Connection Manager version 2.19.0

Keeper Remote Browser Isolation

The Remote Browser Isolation connection type provides secure access to web-based application through a rendered, isolated browser experience. The website's code and DOM never executes locally on the user's device, so the user is immune to many different types of attack vectors. There are other major security benefits to this technology which protect the asset from local device attacks, since the web browser session is not running on the local environment.

Replaces the need for VPNs, ZTNAs or other ad-hoc networking solutions By simply publishing a Keeper Connection Manager container to any target environment, access to web-based resources can be restricted, monitored and controlled.

Zero Knowledge Architecture The customer is in full control of all network communications between the user's device and the target websites and applications. Powered by the Chromium Engine Keeper Remote Browser Isolation is projecting a virtualized instance of the latest version of the Chromium browser from the Keeper Connection Manager container through the user's device, without transmitting any confidential or sensitive data.

Session Recording Just like other Keeper Connection Manager protocols, 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.

Parameters

Keeper's support for Remote Browser Isolation is controlled through the use of several parameters. When a database like MySQL or PostgreSQL is used in the deployment of the container, these parameters are stored in the database and presented in the web interface. If defining connections through another mechanism, such as through encrypted JSON or LDAP schema modifications, parameters are specified using their internal parameter names.

This document is intended to cover all supported parameters, grouped in the same way they are grouped within the web interface. The field headings which would appear in the web interface are provided for each parameter, along with each parameter's internal name and a thorough description of the behavior and legal values for that parameter.

• Keeper Secrets Manager parameters

• Browser Setting parameters

• URL Patterns

• Browser Autofill parameters

• Secrets Autofill Configuration

• Self-signed or custom CA certificates

Keeper Secrets Manager parameters

This setting allows users to integrate their own Keeper Secrets Manager application for credential autofill.

Field header	Parameter name	Description
Allow user-provided KSM configuration:	ksm-user-config-enabled	If set to "true", each Keeper Connection Manager user profile can be assigned to a Keeper Secrets Manager configuration for any connection. See the Multiple Vaults Integration screen for more information.

Browser Setting parameters

Remote Browser Isolation connections are established through a rendered chromium browser experience. In general, each connection is associated with a specific web app, but can be configured to allow broad web browsing as well.

Browser Settings

By default, every new Remote Browser Isolation session is the equivalent of an "incognito" window, where the local storage is cleared. This supports multiple simultaneous concurrent users to perform RBI sessions without any retention of data.

If you provide a "Browser Profile Storage Directory" value, the browser session data is retained within the KCM guacamole container. As an example, using a path constructed like below will retain the browser session on a per-user basis:

/var/lib/guacamole/rbi-profiles/this-site/${GUAC_USERNAME}

In this example, the connection profiles will be stored in the this-site folder under a subfolder according to the logged-in user.

Browser Profile Storage Directory

Note: The same browser profile storage directory cannot be used concurrently from multiple sessions.

Field header	Parameter name	Description
Allow navigation via direct URL manipulation	allow-url-manipulation	Whether the user should be allowed to edit the current URL, navigate backward and forward, etc. as they would in a traditional browser. If checked (set to true), the user will be presented with navigation bar when they open the connection. By default, users are not allowed to manually edit the current URL, and can navigate only through interacting with the current page.
URL	url	The URL of the page that should be initially loaded when a user connects.
Allowed URL Patterns	allowed-url-patterns	The patterns of all URLs that the user should be allowed to visit, regardless of whether via manual navigation (URL bar) or interacting with the current page. Multiple patterns may be specified, separated by newlines. If specified, only pages matching patterns in the list are permitted. By default, all URLs are permitted.
Allowed Resource URL Patterns	allowed-resource-url-patterns	The patterns of all URLs that the a page should be allowed to load as a resource, such as an image, script, stylesheet, font, etc. Multiple patterns may be specified, separated by newlines. If specified, only resources matching patterns in the list are permitted to be loaded. By default, no restrictions are imposed on resources loaded by pages.
Browser Profile Storage Directory	profile-storage-directory	Location in the guacamole container where the browser session data is retained.
Automatically Create Profile Directory	create-profile-directory	The possible values are: "false" (default), "true" and "recursive"

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:

Pattern	Meaning
accounts.google.com	Allow requests to the domain accounts.google.com involving any protocol and any path. Requests must be made to the standard port for whatever protocol is involved.
*.youtube.com	Allow requests to any subdomain of youtube.com involving any protocol and any path. Requests must be made to the standard port for whatever protocol is involved.
http://10.10.10.10:8080	Allow requests to 10.10.10.10 on port 8080 using strictly HTTP (not HTTPS) and any path.
10.10.10.10:*	Allow requests to 10.10.10.10 on any port using any protocol and any path.
https://example.net/foo	Allow requests to example.net using strictly HTTPS (not HTTP) and the path “/foo”. Requests must be made to the standard port for HTTPS.
https://example.net/foo/*	Allow requests to example.net using strictly HTTPS (not HTTP) and any path beneath “/foo”. Requests must be made to the standard port for HTTPS.
google.com	This would allow any protocol or path from google.com root domain, but does not allow a subdomain.

Browser Autofill parameters

Keeper Connection Manager provides the capability of autofilling a username and password into a target website login screen. The username and password can be supplied directly in the user interface, or it can be provided as a reference to a record from the Keeper vault.

Browser Autofill Parameters

Secrets Autofill Configuration

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 value filled will be the value of the username parameter for the connection.

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

• 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:

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

Basic Autofill Parameters Example

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:

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

[
    {
        "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>:

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

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

Integration with Keeper Secrets Manager

The Username and Password information can also be retrieved directly from the Keeper Vault using the Keeper Secrets Manager integration. For example, logging into Jenkins with a Username and Password from the Keeper Vault will perform a lookup based on a custom field called "Hostname".

Browser Autofill Parameters with Keeper Secrets Manager integration

The Keeper Vault record is stored with a format as seen below:

Keeper Vault Configuration

Audio Setting parameters

Audio Settings

Field header (web interface)	Parameter name	Default Value	Description
Disable Audio	disable-audio	false	If checked (set to true), audio will not be forwarded within the RBI session. Pages will still be able to attempt to play audio; the audio will simply be ignored.
Channels	audio-channels	2	The number of separate audio channels that should be used for audio data sent through KCM. Valid values are: 1 (monaural audio with only a single, center channel, more commonly called ("mono") 2 (stereophonic audio with left and right channels, more commonly called "stereo").
Bit Depth	audio-bps	16	Valid values are: 8 (8-bit audio, a relatively low quality) 16 (16-bit audio, a standard level of quality)
Sample Rate	audio-sample-rate	44100	The sample rate (in Hz) that should be used for any audio data sent through KCM.

Self-signed or custom CA certificates

If your target web application uses self-signed or custom CA certificates, populate the CA_CERTIFICATES environment variable in the Docker Compose to allow those certs. See the guacd parameter documentation at this link for an example.

Browser Isolation FAQ

Is this feature only for Keeper Connection Manager?

Yes, Remote Browser Isolation is an add-on for Keeper Connection Manager.

Being part of Keeper Connection Manager, does this imply that the Remote Browser Isolation functionality is not targeted for the general user population?

No, Remote Browser Isolation has been created with a range of use cases in mind. End-users can now be provided access to internal web-based applications without the requirement of a VPN or ZTNA product. Remote Browser Isolation also does not require the need for a local agent on their device.

Is this only for Linux?

No, Remote Browser Isolation works across Windows, Mac, Linux, Android and iOS.

Does this only work through Docker containerization or will it work through Kubernetes as well?

Keeper Connection Manager is deployed as docker containers which can be used as the runtime in a Kubernetes deployment.

Is the RDP limited to a single screen?

Keeper Connection Manager can be stretched across multiple screens and if users would prefer an individual window for each monitor, additional browsers with KCM opened can be used.

Can this work with a PAM solution like Centrify?

Yes, users can log into any web application or website through Remote Browser Isolation for secure, recorded sessions.

Can you copy and paste from local to the browser connection?

Yes, as long as it is not disabled by the admin. There are browsers that do not support that level of clipboard integration.

Does this replace the need for a VPN for remote team members outside of the US?

Yes, Remote Browser Isolation with Keeper Connection Manager can replace the need for VPNs to access an internal web application or specific cloud-based apps.

Can Connection Manager access local USB devices like scanners?

Not currently. We are researching this capability to potentially add it to the roadmap.

Does this prevent phishing or malicious websites inserting something on my local device?

Yes, all activity happens in the RBI sandbox, preventing phishing or malicious actors from attacking your local device.

Is it possible to route traffic through proxy?

Remote browser isolation sessions require that the machine hosting the KCM container can query DNS and make web requests to the target websites and applications. If the targets are not accessible from your KCM instance, please contact support to review your configuration.

How much storage do recordings typically take up and are there storage costs associated with the recordings?

Recordings are stored in the KCM container, so there are no charges associated from the Keeper side. The size of the recordings will depend on the length and volume of UI interaction.

How does this impact downloading to the local machine?

Currently, downloading and uploading files is blocked. In a future update of KCM, the ability to control both file upload and file download will be available in the connection settings.

Could this be a replacement for CyberArk?

Yes, KeeperPAM provides password and passkey management, secrets management and connections management to provide a full zero-trust approach to privileged access management. To learn how Keeper compares to CyberArk and many other competitors please visit: https://www.keepersecurity.com/vs/competitors/

Does this have FIPS certification so you can access CUI?

Keeper utilizes FIPS 140-2 validated encryption modules to address rigorous government and public sector security requirements. Keeper’s encryption has been certified by NIST Cryptographic Module Validation Program (CMVP) and validated to the FIPS 140 standard by accredited third-party laboratories. Keeper has been issued certificate #3976 under the NIST CMVP. To learn more about Keeper’s security, encryption and compliance, please visit: https://www.keepersecurity.com/security