Web applications in the RDS Proxy (WebView)

• Back to the RDS Proxy main page

A web target turns an RDS Proxy session into one web application.
The user starts the usual Remote Desktop client, connects to the gateway and picks the application.
The page opens inside the Remote Desktop window, without address bar, tabs or menus.

The problem it solves

Administration consoles, ERP screens and intranet tools are often web applications.
Opening them from the workstation means a direct network path from the workstation to the application.
It also means the browser of the workstation keeps the session cookies and the saved passwords.

With a web target, the browser runs on the bastion.
The workstation only receives images over RDP and sends the keyboard and the mouse.
The application only sees the bastion.
No Windows server is needed to host the browser.

The workstation reaches the gateway only.
The browser runs on the bastion, in a sandbox, behind a filtering proxy.

How it works

1. The user opens a Remote Desktop connection to the Artica appliance.
2. The gateway checks the account, the source network, the schedule and, when the policy asks for it, the second factor.
3. The user picks a web target in the list of applications.
4. The bastion starts a headless Chromium for this session only, in a bubblewrap sandbox, under an unprivileged account.
5. The page of the application is drawn in the Remote Desktop window.
   Only the parts of the screen that change are sent, and a scroll is sent as a scroll.
6. When the session ends, the browser and everything it wrote are destroyed.

A web target is a target like the others.
It goes through the same policies, the same second factor, the same video recording and the same access events.

Benefits

• No path from the workstation to the application.
  The application can stay in a network that only the bastion reaches.
• Nothing to install.
  The workstation needs only the Remote Desktop client.
  No Windows server, no browser plug-in, no agent on the application.
• Only the allowed sites.
  The page can load content only from the sites listed on the target.
  Every other navigation shows a blocked page.
• The bastion protects itself.
  The browser cannot reach the bastion, its local addresses or its loopback, even through a redirection.
• Credentials stay in the vault.
  The bastion can sign in to the application with an account the user never sees.
• Controlled copy and paste.
  Each direction is a right of the policy, and every copy and paste is counted in the events.
• Full trace.
  Visited pages, blocked pages, closed pop-ups, sign-ins, copies and pastes go to the access events and to the SIEM.
  The session is recorded on video like an RDP session.
• Per-policy network.
  A policy can confine its browsers to a network namespace, or send their traffic to an upstream proxy.
  A PAC file can choose the exit address by address.
• The target is always named.
  A band at the top of the session shows the target and the host of the page.

What the user can and cannot do

Requirements

Artica installs chromium-headless-shell and bubblewrap with apt when the RDS Proxy is installed.
If one of them is missing, it tries again every 6 hours.
The installation needs 600 MB free on /usr.
The WebView tab shows each component, its version and what is missing.

Limits

• One application per target.
  A user who needs two applications gets two targets.
• The browser has no display, camera or microphone of its own.
  WebGL and 3D are disabled.
• Downloads, uploads and printing are refused.
• Copy and paste is text only.
  The right-click menu of the page cannot paste: use Ctrl+V or Shift+Insert.
• The session limit of the RDS Proxy license applies to web sessions too.

Documentation pages