Isolated browser

An application with mode: isolated in apps.yaml is not opened in the user's own browser. A browser runs for the user on a dedicated RBI host (the isg_rbi group), in a container with no network, and the user's browser only receives its picture. The rest of Web Access stays the same: the request-level audit, the http_rules, the kind: form sign-in and the cookies the broker keeps. How a request travels is on how Web Access works, and how an application is configured is on configuring applications.

What the user sees

The application opens at /_isg/rbi/view on its own host name. The page shows the remote browser's picture and forwards the mouse and the keyboard. The clipboard is blocked in both directions. The remote browser's managed policy blocks downloads, the file chooser, printing, the developer tools and the password manager.

The remote screen follows the size of the user's window: the remote browser fills it, and the watermark stays in its corners.

The bar above the picture has a full-screen button: it switches the whole view to full screen and back. F11, the browser's own full screen, also works: the key stays with the user's browser and does not reach the remote one.

Two corners of the picture carry a watermark: the user, the application and the current time, updated every minute. It is drawn on the remote screen, so it is also in the recording, and the user cannot remove it from their own browser.

How a session runs

• The broker that serves the user starts the session on the least loaded live agent (isg rbi-agent run on each RBI host, polling the brokers over mTLS) and waits up to session_start_timeout_seconds for it.
• The container's only way out is one socket per session. The agent carries every connection on it to the broker that owns the session, and the broker's own application proxy sends the request upstream. So the policy, the approval, the ticket and the request log are the ones of an ordinary Web Access session.
• If the user closes the page, the browser keeps running for viewer_grace_seconds (default 300; an application's own viewer_grace_seconds in apps.yaml overrides it, and an RDP application waits 60 seconds). A user who comes back within that time, after a reload or a dropped connection, gets the same browser. After it the browser stops and the application session ends with it (APP_RBI_SESSION_CLOSED, reason viewer_gone). Opening the application again is a new session; an application that needs approval asks for it again.
• If an RBI host stops polling for agent_stale_seconds, its sessions end (reason agent_lost). A session is not moved to another host.

Second factor on a request

A step_up rule works on an isolated application too. The remote browser cannot reach the web UI, so the confirmation happens in the user's own browser: the remote page says a confirmation is needed, a bar appears at the top of the view, and its button starts the usual step-up. After it the remote page reloads by itself and the request goes through. The audit line is APP_STEP_UP_REQUIRED, as for any other application.

Recording

Every isolated session is recorded as a picture, in the Guacamole format the RBI host writes. Keystrokes are not recorded. When the browser stops, the agent sends the recording to the broker that owns the session, which keeps it as the session's recording (APP_RBI_RECORDING_STORED). From there it travels like a terminal recording: archived to the recording store, kept and purged by the same retention rule, checked by isg storage verify. The RBI host holds no storage credentials. After a broker restart or an interrupted upload, the agent's retry lands in the same recording, once.

The recording plays back on the session's page in the web UI, for an administrator or the session's owner. It is capped at recording_max_mb (default 2048) per session.

Live view and termination

An administrator who may close sessions can watch a running isolated session at /sessions/live, linked from the sessions table. The view is read-only: the viewer's mouse and keyboard do not reach the remote browser. It works on the broker that runs the session; another broker's web UI says where the session runs. Each view is an audit line (APP_RBI_LIVE_VIEW_STARTED and its end). Closing the session from the same table ends the remote browser too.

Configuration

• apps.yaml: mode: isolated on the application.
• rbi.yaml on the brokers (see rbi.example.yaml): the agents, the CA files, the timings above and recording_max_mb. The Ansible config source writes it when the inventory has an isg_rbi group.
• rbi-agent.yaml on each RBI host (see rbi-agent.example.yaml): the brokers, the identity, recordings_dir and the per-session limits. The isg_rbi role writes it and enrolls the agent.

Measured on one RBI host with 4 vCPU and 8 GB: a console-like page uses about 250 MB per session and a few percent of the CPU, so memory sets the limit at about 25 sessions; a video-like page uses most of a core, so the CPU sets it at one or two sessions.

What the isolated browser is not

• It does not record keystrokes, and it does not export video files: playback is in the web UI.
• It does not carry files in either direction, and it has no clipboard.
• It does not survive the loss of its RBI host: the session ends.