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.
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.
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:
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:
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.
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
Field header | Parameter name | Description |
---|---|---|
Field header | Parameter name | Description |
---|---|---|
Field header (web interface) | Parameter name | Description |
---|---|---|