Remote Browser Isolation

Advanced configuration of HTTP/HTTPS Remote Browser Isolation connection type

This feature is going live with KCM version 2.19.0 in May 2024

Overview

The HTTP/HTTPS (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.

Keeper's support for the HTTP/HTTPS protocol is controlled through the use of several parameters. When a database like MySQL or PostgreSQL is used, these parameters are presented in a convenient 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

Field headerParameter nameDescription

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

HTTP/HTTPS 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:

/var/lib/guacamole/rbi-profiles/some-website-${GUAC_USERNAME}

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

Field headerParameter nameDescription

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.

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.

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']"

Some login flows will require multiple rules. For example, the Microsoft Azure Portal login flow would be an example of this. For complex pages, you may also specify:

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

Additionally, 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 /.

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']"
    }
]

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

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

Audio Setting parameters

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.

Last updated