9.2 PSM HTML5 Gateway Architecture & Clientless Web Access

9.2 PSM HTML5 Gateway Architecture & Clientless Web Access

Quick Answer: The PSM HTML5 Gateway is an enterprise session proxy based on Apache Guacamole that delivers completely clientless, browser-based privileged access. In standard PSM workflows, launching a session requires users to download an .rdp file and run a local Remote Desktop client (mstsc.exe), requiring outbound TCP port 3389 from the client workstation to the PSM server. The HTML5 Gateway eliminates both requirements: the entire RDP or SSH privileged session is rendered inside an HTML5 <canvas> element within a browser tab, channeling all user traffic over secure HTTPS on TCP port 443 (via WebSockets). This architecture is critical for securing external contractors, remote teleworkers, macOS/Linux users, and locked-down zero-trust networks.

---

The Limitations of Native RDP Clients & The Zero Trust Imperative

In traditional CyberArk PAS deployments, clicking Connect in PVWA generates a temporary, cryptographically signed .rdp file. The user's browser downloads this file, which launches the local Windows Remote Desktop client (mstsc.exe on Windows or Microsoft Remote Desktop on macOS).

While functional for managed corporate Windows desktops, this model introduces operational and security challenges:

• Egress Firewall Restrictions: Corporate firewalls, branch offices, and client environments often block outbound TCP port 3389 (RDP) to prevent lateral movement and ransomware propagation.
• Endpoint Client Dependencies: Non-Windows devices (macOS, Linux, Chromebooks, tablets) require pre-installed, compatible RDP software that may not support custom CyberArk session parameters.
• Client-Side File Artifacts: Downloaded .rdp files reside temporarily in local download directories. Although tokenized, security policies frequently prohibit writing connection files to unmanaged endpoints.
• Data Exfiltration Vectors: Native RDP clients can expose local drives, printers, and clipboards to the remote session unless suppressed by endpoint Group Policy Objects.

The PSM HTML5 Gateway eliminates these constraints by decoupling client endpoints from native remote desktop protocols.

---

PSM HTML5 Gateway Core Architecture

The HTML5 Gateway is an appliance package built on open-source Apache Guacamole, hardened specifically for the CyberArk PAS suite.

Apache Guacamole & Apache Tomcat

The gateway consists of two primary internal tiers:

• Guacamole Web Application (cws.war / guacamole.war): A Java application hosted in an Apache Tomcat servlet container. It terminates incoming HTTPS (TCP port 443) connections from user browsers, manages WebSocket and HTTP tunnels, validates session tokens from PVWA, and converts session graphics into HTML5 canvas draw commands.
• Guacamole Proxy Daemon (guacd): A native, multi-threaded C daemon on Linux that executes protocol translation. When instructed by Tomcat, guacd establishes downstream native RDP connections (TCP 3389) to the Windows PSM server or native SSH connections (TCP 22) to Unix targets, translating RDP primitives into the Guacamole protocol.

Deployment Models: Containerized Docker vs. Standalone RPM

• Containerized Deployment (Docker / Podman): The HTML5 Gateway is packaged as pre-hardened container images distributed by CyberArk. Tomcat, guacd, and configuration templates run inside isolated containers, simplifying upgrades and cloud deployments.
• Standalone Package Deployment (RPM): Tomcat, guacd, and dependencies are installed directly on enterprise Linux (RHEL, CentOS, Rocky Linux) and managed via systemd.

---

End-to-End Session Data Flow

Understanding the multi-tier handshake across the HTML5 Gateway is a foundational objective for the PAM-DEF exam:

1. PVWA Session Request: The user logs into PVWA over HTTPS (TCP port 443) and clicks Connect on an account configured for HTML5 access. PVWA validates authorizations and requests a session token from the Vault over TCP port 1858.
2. Browser Redirection (HTTPS 443): PVWA opens a new browser tab directed to the HTML5 Gateway URL. The browser establishes a secure WebSocket connection (wss://<Gateway_FQDN>:443/guacamole/websocket-tunnel) or falls back to an HTTP tunnel over HTTPS.
3. Mutual TLS (mTLS) Authentication: The HTML5 Gateway validates the session token with PVWA. The connection between PVWA and the gateway is secured using Mutual TLS (mTLS), where both servers authenticate each other using trusted digital certificates.
4. guacd to PSM Brokering (RDP 3389): Once verified, the Guacamole web app instructs guacd to initiate an internal RDP session to the Windows PSM jump server over TCP port 3389.
5. PSM Vault Retrieval & Target Execution: PSM contacts the Digital Vault over TCP port 1858 to retrieve the target credential, launches the target session (RDP 3389 to Windows or SSH 22 to Unix), and begins recording.
6. Graphics Conversion & Canvas Rendering: As the target session updates, PSM sends RDP frames to guacd. The guacd daemon translates RDP differentials into Guacamole instructions for Tomcat. Tomcat streams compressed instructions over the WebSocket tunnel to the browser, where JavaScript renders them inside an HTML5 <canvas> element.

---

High Availability, Scalability & Load Balancing

For enterprise environments with high concurrent session volumes, high availability (HA) and load balancing are essential:

• Application Load Balancers (ALB): Multiple gateway nodes deploy behind an ALB (F5 BIG-IP, Citrix ADC, AWS ALB, Nginx) listening on TCP port 443.
• WebSocket Support: The load balancer must explicitly support HTTP connection upgrades to WebSockets (Connection: Upgrade and Upgrade: websocket).
• Session Affinity (Sticky Sessions): Because Guacamole maintains stateful in-memory tracking of active sessions, load balancers must enforce session stickiness so packets for an active session route to the same gateway node.
• Capacity Sizing: A standard gateway node (4 vCPUs, 8 GB RAM) supports 50 to 100 concurrent active sessions, depending on screen resolution and visual activity.

---

Security Hardening & Zero Trust Governance

The PSM HTML5 Gateway provides vital security benefits for Zero Trust architectures:

• Zero Client-Side File Storage: Because no .rdp file is written to the client endpoint, session parameters cannot be inspected, modified, or replayed by endpoint malware.
• Data Loss Prevention (DLP): Client-side drive mapping is eliminated because the browser sandbox cannot provide the remote target with direct local filesystem access. Clipboard operations can be restricted or disabled via platform policy.
• Mutual TLS Protection: Mutual TLS ensures external threat actors cannot interact directly with the HTML5 Gateway servlet without presenting a trusted client certificate.

---

Native PSM RDP vs. PSM HTML5 Gateway