Session workflow

  • User requests to initiate an application by invoking a "play" action URL from the Portal in the form: https://online.cameyo.com/apps/1234..../play. This can also be invoked through a Cameyo API.
  • Portal checks the user's authentication for this application. If authentication is required but missing, the portal authenticates the user either through login credentials or the configured SSO provider. SSO can be any OIDC-compliant provider, including Azure AD, Google, Okta, Ping etc.
  • Portal determines the best execution server to serve the request. If there is more than one server, it performs load-balancing based on each server's available resources (CPU + RAM), number of current sessions running on that server, and distance from the user. In cloud environment the portal orchestrates cloud instances as needed, including powering up and/or cloning new servers as needed.
  • Portal contacts the best-available execution server and instructs it to prepare to host a session for the request app for that user.
  • Execution server performs any necessary preparations, including provisioning the user's Windows profile and synchronizing the user profile's data (registry & files) if SessionSync is enabled. If the client is RDP-based (as opposed to HTML5), Cameyo's RDP Port Shield opens RDP port for the user's IP.
  • Execution server responds to the portal with the connection details. The portal translates them to the client:
    • HTML5 client: user's browser is forwarded directly to the server's HTTP/S address with a given token. That token is then verified by the execution server against the portal.
    • Native Windows / Android rdp clients: connection is made directly through RDP, using one-time credentials generated on-the-fly and transmitted to the client.
  • Session runs according to Cameyo's policy settings such as: maximum time / idle time, cloud storage virtualization / synchronization, shell lockdown, toolbar options, file transfer permissions etc.
  • Upon session's end, user profile is cleaned up. If Cameyo is configured to "Temporary User Profiles", the entire user profile data is wiped out of the server. If SessionSync is enabled, this is done after synchronizing the user's data back to the central / cloud storage.

Components

Client

Cameyo offers two types of clients: HTML5 (URL) and native:

  • HTML5: published application is accessible through a simple URL, and the session is rendered within the browser. This is the most universal Cameyo client, and is easily accessible from any device anywhere.
  • Native clients (Windows, Android): session is performed directly through the RDP port. In such scenario, the relevant execution server's RDP port is opened on-the-fly for the user's specific IP prior to start a session. This client requires a lightweight component installation upon the first user connection. Native clients have some advantages such as redirection of USB, printing and local drives.

Play servers (execution servers)

Execution servers are offered either from the cloud -- pre-configured and provisioned upon need, or self-hosted. Self-hosted servers are automatically configured by Cameyo during installation, without any required prerequisite other than a supported, up-to-date pristine Windows Server. Cameyo also properly sets the file system security permissions for the components it installs.

Each Cameyo server possesses its own ID (GUID) and private key, generated upon installation.

The installation and configuration of the following components is made automatically during the server installation:

  • RDS: enables multi-session RDP communication into the server.
  • Apache Tomcat: hosts HTTP/S for HTML5 sessions.
    • Location: C:\RapPrereqs\Tomcat
    • Apache Tomcat 9 service (Tomcat9)
    • Logs: C:\RapPrereqs\Tomcat\logs
    • Configuration: C:\RapPrereqs\Tomcat\conf
    • Cameyo's applet files: C:\RapPrereqs\Tomcat\webapps\ROOT
    • HTTPS certificate: managed by Cameyo (cloud) or added manually when needed.
    • Preconfigured with AJP connector disabled.
  • Apache Guacamole server + client.
  • Java Runtime for supporting the Apache components.

Cameyo backend components

Cameyo's backend server agent is installed on execution servers in C:\RemoteAppPilot and is composed of several Windows components:

  • Cameyo's service (RapStartSvc): runs as a SYSTEM service. In charge of auto-updating Cameyo's server agent components and running RemoteAppPilot.exe.
  • RemoteAppPilot.exe: manages the entire Cameyo session workflows including interaction with the portal, session setup, initiation, startup, policy enforcement, user profile lifecycle management, and storage synchronization.
  • VirtPH.exe + AppVirtDll*.dll: low-level hooks of Windows applications, for implementing helper functions such as: file open / save dialog replacement, cloud storage virtualization, registry virtualization where needed, app compatibility virtualization.

Portal

Cameyo's portal is served from the cloud. It is composed of 3 endpoints, all of which go through Cameyo's load balancer:

  • Portal (online.cameyo.com / company.cameyo.com): serves as front-end user / admin interaction.
  • API server (api.cameyo.com): controller and load-balancer for session execution, as well as API endpoint serving Cameyo servers.
  • Files server: files.cameyo.com: used for distributing the latest back-end components to execution servers.

Components diagram



Network architecture

Although natively designed for the cloud, Cameyo offers a flexible combination of on-premises and cloud. In its simplest deployment form, all of Cameyo's components are in the cloud. This diagram presents Cameyo's different components:

Fully-hosted server (cloud deployment)

Self-hosted server (on-premises deployment)

BYO Cloud: self-provided GCP / Azure



Communication between the end-user's device and Cameyo's execution servers can be tunneled through Cameyo's Secure Cloud Tunneling. This mode is enabled mostly in on-premises situations, where the execution servers are behind corporate firewalls and direct incoming port connection is not available or wanted.



Session segregation and security

Cameyo segregates user sessions from the system and from other user sessions at OS level, which is the strongest possible level.


Security

Cyber attacks are a considerable risk to any IT system -- be it on-premise or cloud-based. Security is at the core of Cameyo's design rather than an after-thought. For more information, see Cameyo vs security risks, vulnerabilities and attacks.