Advanced configuration of HTTP/HTTPS Remote Browser Isolation connection type
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 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.
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 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:
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 |
---|---|---|
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.
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"
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.
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.