AppsAnywhere Process and Data flow

Introduction

This document provides a summary of the AppsAnywhere process and data flow for both the basic system design and the standard operations that are performed.

A summary of data captured and/or stored at various points is also provided.

Please note that the focus of this document is the AppsAnywhere product. 

Details of Numecent Cloudpaging and Parallels RAS are only covered from the integration standpoint. 

However, a brief traffic flow summary is included for these products.

AppsAnywhere

Basic Design

The following sections provide a basic and example system design for the various products.  These do not include all components and modules that can be part of the solution, specifically with Parallels RAS.

Although the AppsAnywhere, Numecent Cloudpaging and Parallels RAS configurations below have been separated, the environment is normally combined.

AppsAnywhere and Numecent Cloudpaging

The Infrastructure Diagrams provide details of an example/basic system design for AppsAnywhere with Numecent Cloudpaging.   

User login to AppsAnywhere

The following diagram provides an overview of the AppsAnywhere login sequence.

This process is actioned when the user accesses AppsAnywhere through their browser.  All access to the AppsAnywhere instance is via HTTPS/443. 

The “authenticate user” process will authenticate the user using the credentials supplied with one of the DC’s in the linked active directory domain.  This will use Kerberos where available but will fall back to NTLM if required.

By default, the following user information is written into the AppsAnywhere database.

NOTE: There are additional values/fields at are populated which are not listed.  However, these are internal fields like unique identifiers and tour progress etc which do not contain user specific information.

If AppsAnywhere Analytics is enabled (which is not+ enabled by default) a login event is written to the Analytics database by the AppsAnywhere server currently processing the request.  This event contains the following information user and device information: -

NOTE: There are additional values/fields at are populated which are not listed.  However, these are internal fields like unique identifiers etc do not contain user specific information.

User validation (Windows and MAC only)

The following diagram provides an overview of the AppsAnywhere validation sequence.  This process will only occur if the user has been successfully authenticated as detailed in the previous step. 

This process only occurs on Windows and macOS devices.

The validation information is collected from the device and passed to the AppsAnywhere server via an encrypted message.  All communication between the AppsAnywhere Client and Server is performed over HTTPS/443.

The encrypted message contains the following user and device information: -

This validation information is only used within the active session to filter the list of available objects the user sees within the AppsAnywhere Portal.  None of this information is stored in the AppsAnywhere database.

If AppsAnywhere Analytics is enabled (which is not enabled by default) device information is written to the Analytics database by the AppsAnywhere server currently processing the request.  This event contains the following information device information: -

NOTE: There are additional values/fields at are populated which are not listed.  However, these are internal fields like unique identifiers etc do not contain device specific information.

 Launch Cloudpaged application

The following diagram provides an overview of the AppsAnywhere sequence of the user launching a Cloudpaged application.  This process will only occur if the user has been successfully authenticated and validated as detailed in the previous steps.  This process also only applies to Windows devices.

All communication between the AppsAnywhere Client and Server is performed over HTTPS/443.

The AppsAnywhere Client is passed the launch request via the browser in an encrypted string format.  The AppsAnywhere Client decodes the request and determines the required actions.  In this case the request is for a Cloudpaged application. 

At first the AppsAnywhere Client will determine the minimum required version of the Cloudpaging Player as defined within the AppsAnywhere admin portal.  If it is not installed or an older version, it will be installed or upgraded automatically.

Once the Cloudpaging Player requirements have been met, a partial validation of the user and device takes place.  This is due to user and OS restrictions assigned to the select delivery methods, in this case Cloudpaging.

The partial validation information is sent via an encrypted message which contains the following user and device information: -

If all criteria have been met the AppsAnywhere Client will send a request to the AppsAnywhere Server for a secure Cloudpaging token for the required application.  In turn, the AppsAnywhere Server will contact the Cloudpaging Admin/License server(s), which then issues the secure token.  The token is then returned to the AppsAnywhere Client by the AppsAnywhere Server.

This secure token is received by the AppsAnywhere Client and passed to the Cloudpaging Player.

The Cloudpaging Player will then process the request, virtualize the application and launch it once complete.

As part of this request the following user and device information is stored within the AppsAnywhere and Cloudpaging databases.  This information is linked to the users/device unique session ID.

If AppsAnywhere Analytics is enabled (which is not enabled by default) a launch and session entry are added which are linked to the previously stored device and user information.

As part of the continued session authentication performed by the Cloudpaging Player while the application is virtualized and/or running, the Player will send a token renewal request to the AppsAnywhere Server over HTTPS/443.  The secure token file is reissued if the renewal is successful.  The renewal request contains the unique session ID that is assigned when the application is first cloudpaged.

For the delivery of the Cloudpaging virtualized application content, the Cloudpaging Player will communicate directly with the Cloudpaging Paging servers.  This communication is performed over HTTP/80.  Even though the requests and data are sent/received over HTTP, the content is encrypted so is not readable by anything other than the Cloudpaging Player.  The default encryption level is 256bit AES, however this is configurable during the application/content packaging process.