Remote Browser Isolation
Advanced configuration of HTTP/HTTPS Remote Browser Isolation connection type
Last updated
Advanced configuration of HTTP/HTTPS Remote Browser Isolation connection type
Last updated
This feature has been published live with Keeper Connection Manager version 2.19.0
The Remote Browser Isolation connection type provides secure access to web-based applications 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.
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.
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: |
| 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. |
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.
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:
In this example, the connection profiles will be stored in the this-site folder under a subfolder according to the logged-in user.
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 |
| 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 By default, users are not allowed to manually edit the current URL, and can navigate only through interacting with the current page. |
URL |
| The URL of the page that should be initially loaded when a user connects. |
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 |
| 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 |
| Location in the guacamole container where the browser session data is retained. |
Automatically Create Profile Directory |
| The possible values are: "false" (default), "true" and "recursive" |
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 |
| Allow requests to the domain |
| Allow requests to any subdomain of |
| Allow requests to |
| Allow requests to |
| Allow requests to |
| Allow requests to |
| This would allow any protocol or path from |
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.
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:
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:
Here's the equivalent, formatted as JSON:
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:
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 /.
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.
Inspect the Page: Open the developer tools by right-clicking on the webpage and selecting "Inspect."
Select the Field: Use the element selector tool to click on the form field you want to identify.
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.
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>:
If the field is found, the DOM element will be displayed. Otherwise, an error will be displayed.
The guacd container can be modified to include a file that contains autofill rules. Using this file, you don't need to load the same rules for all connections. The rules are appended to any rules that appear for a specific connection.
Modify your docker-compose.yml file to include a mapping of autofill-rules.yml as see below:
Example autofill-rules.yml file:
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".
The Keeper Vault record is stored with a format as seen below:
Field header (web interface) | Parameter name | Default Value | Description |
Disable Audio |
|
| If checked (set to |
Channels |
|
| The number of separate audio channels that should be used for audio data sent through KCM. Valid values are:
|
Bit Depth |
|
| Valid values are:
|
Sample Rate |
|
| The sample rate (in Hz) that should be used for any audio data sent through KCM. |
Remote Browser Isolation sessions can be recorded graphically. These recordings take the form of Guacamole protocol dumps and are recorded automatically to a specified directory. Recordings can be played back in the Connection Manager user interface or the files can be played in the open source player.
The player is a static web application, using only JavaScript to play back provided recordings. This functionality is implemented strictly locally; the recordings are not uploaded to a remote service for processing. If you would prefer to use your own deployment of this application, or would like to investigate the source, the full source of the Keeper Connection Manager Session Recording Player can be found on GitHub, along with instructions for local deployment: https://github.com/glyptodon/glyptodon-enterprise-player
The latest version of Keeper Connection Manager supports on-screen playback of recorded sessions. See the Session Recording documentation page.
| Field header (web interface) | Parameter name | Description |
|---|---|---|
Recording path: |
| The directory in which screen recording files should be created. If a graphical recording needs to be created, then this parameter is required. Specifying this parameter enables graphical screen recording. If this parameter is omitted, no graphical recording will be created. |
Recording name: |
| The filename to use for any created recordings. If omitted, the filename of each recording will simply be "recording". Guacamole will never overwrite an existing recording. If necessary, a numeric suffix like ".1", ".2", ".3", etc. will be appended to the filename to avoid overwriting an existing recording. If even appending a numeric suffix does not help, the session will not be recorded, and an error will be logged. This parameter only has an effect if graphical recording is enabled, which is controlled by specifying a recording path. If the recording path is not specified, graphical session recording will not be enabled, and this parameter will be ignored. |
Exclude graphics/streams: |
| If set to "true", graphical output and other data normally streamed from server to client will be excluded from the recording, producing a recording which contains only user input events. By default, graphical output will be included in the recording. This parameter only has an effect if graphical recording is enabled, which is controlled by specifying a recording path. If the recording path is not specified, graphical session recording will not be enabled, and this parameter will be ignored. |
Exclude mouse: |
| If set to "true", user mouse events will be excluded from the recording, producing a recording which lacks a visible mouse cursor. By default, mouse events will be included in the recording. This parameter only has an effect if graphical recording is enabled, which is controlled by specifying a recording path. If the recording path is not specified, graphical session recording will not be enabled, and this parameter will be ignored. |
Exclude touch events: |
| If set to "true", user touch events will be excluded from the recording, producing a recording which lacks the exact details of touch interactions. This will not necessarily prevent touch events from being visible, as the remote desktop server may still choose to render touch interaction on its own. By default, touch events will be included in the recording. This parameter only has an effect if graphical recording is enabled, which is controlled by specifying a recording path. If the recording path is not specified, graphical session recording will not be enabled, and this parameter will be ignored. |
Include key events: |
| If set to "true", user key events will be included in the recording. The recording can subsequently be passed through the This parameter only has an effect if graphical recording is enabled, which is controlled by specifying a recording path. If the recording path is not specified, graphical session recording will not be enabled, and this parameter will be ignored. |
Automatically create recording path: |
| If set to "true", the final directory within the specified recording path will automatically be created if it does not yet exist. By default, no part of the recording path will be automatically created, and any attempt to use a non-existent directory will result in the session not being recorded and an error being logged. Only the final directory in the path will be automatically created. If other directories earlier in the path do not exist, the session will not be recorded, and an error will be logged. This parameter only has an effect if graphical recording is enabled, which is controlled by specifying a recording path. If the recording path is not specified, graphical session recording will not be enabled, and this parameter will be ignored. |
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.
Yes, Remote Browser Isolation is an add-on for Keeper Connection Manager.
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.
No, Remote Browser Isolation works across Windows, Mac, Linux, Android and iOS.
Keeper Connection Manager is deployed as docker containers which can be used as the runtime in a Kubernetes deployment.
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.
Yes, users can log into any web application or website through Remote Browser Isolation for secure, recorded sessions.
Yes, as long as it is not disabled by the admin. There are browsers that do not support that level of clipboard integration.
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.
Not currently. We are researching this capability to potentially add it to the roadmap.
Yes, all activity happens in the RBI sandbox, preventing phishing or malicious actors from attacking your local device.
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.
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.
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.
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/
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
