Skip to content

Canvus security overview

Canvus is a software solution for interactive digital collaboration from MultiTaction. It is offered as a self-hosted, on-premise solution that runs entirely inside the customer's own IT infrastructure.

Security architecture

Canvus software uses a client-server architecture. It consists of two main software components: Canvus client and Canvus Connect server.

Canvus client is a native desktop application written in C++ that runs on Windows and Ubuntu Linux operating systems. It can be used on personal computers, such as desktops and laptops, or on dedicated computers connected to an interactive video wall.

Canvus Connect server is used to synchronize multiple Canvus clients. It uses a PostgreSQL database to store information about user accounts and metadata about canvases stored in the system. The server also provides a web UI.

Data flow

Users can connect to Canvus Connect server using the Canvus client desktop application, web browser or by REST API. All communication is initiated by the user.

Info

graph LR

: C(Canvus client) --> S(Canvus Connect server) W(Web browser) --> S R(REST API) --> S

Data transmission

When transmitting data over the network to and from a Canvus Connect server, there are two different scenarios that are available.

When interacting with the Canvus Connect server using a web browser, a single HTTPS connection is formed between the Canvus Connect server and the web browser. All data is encrypted by TLS. The server TLS certificate is used to verify trust between the browser and the server.

When using the Canvus client desktop application, a single custom protocol (not HTTP) connection is formed between the Canvus Connect server and the Canvus desktop client. The protocol encrypts everything using TLS. The server TLS certificate is used to verify trust between the client and the server. The TLS encryption with this custom protocol uses the same certificates and keys as the HTTPS connection between a web browser and the server.

In both scenarios, traffic flows through a single port on the server (by default 443). This includes both the HTTPS traffic from a web browser and the custom protocol traffic from a desktop client. Canvus Connect server will demultiplex the incoming traffic internally.

Man-in-the-middle (MITM) attacks are mitigated by always encrypting all data in transit and by always verifying the TLS certificates on the server. TLS 1.2 is the minimum accepted protocol between the client and server in both web browser and Canvus desktop client scenarios.

Certificates

In order to encrypt data in transit with TLS, Canvus Connect server requires X.509 certificates to be configured. By default, Canvus Connect server will automatically create self-signed certificates without any manual configuration required so that encryption works out-of-the-box.

It is also possible to specify the X.509 certificates manually by the customer in .pem format. This allows the customer to use any Certificate Authority they want.

Customer system integrations

  • Email - Canvus Connect server can integrate with the customer's email server using SMTP. The integration is required for Canvus Connect server to send emails, for example to allow users to reset lost passwords.
  • SAML - Canvus Connect server can integrate with any 3rd party SAML 2.0 Identity Provider for user authentication. For example the customer's own SAML IdP or some external service provider such as Auth0, Okta, or Google.

Audit trail

Canvus Connect server generates an audit trail of security-related events. The audit trail can be viewed by administrator users from the Canvus Connect server's web UI.

The audit trail is available also using a REST API for 3rd party integrations. A manual .csv export of the audit trail is also available in the web UI.

Access control

Canvus provides access control using user accounts and predefined roles. There are two types of user accounts:

  • Regular users are subject to normal access control restrictions.
  • Administrator users can access all content on the server and manage all features of the installation.

A set of predefined roles to restrict access to content is provided. User accounts can also be assigned to user groups for easier access management.

A built-in Guest user account is enabled by default for use in scenarios where easy access to some content is required without having a personal user account in the system. When the Guest user account is enabled, users can also share content from the Canvus Connect server with shared links to specific canvases that require no authentication.

The Guest account can access content on the Canvus Connect server using the Canvus desktop client. Using a web browser, Guest account can contribute content to specific canvases that have been shared using Anyone with the link can edit access.

The Guest account can be blocked to disable any anonymous access to content on the Canvus Connect server and to force all users to authenticate.

Authentication

Canvus Connect server provides two different authentication methods.

  • Local password authentication uses passwords stored in the PostgreSQL database to authenticate users.
  • SAML authentication uses a 3rd party SAML 2.0 Identity Provider to authenticate users.

By default, local password authentication is enabled. It can be disabled if all users are to authenticate with SAML.

QR code authentication

In order to avoid having users enter their credentials on a video wall where it might be visible to other people in the same room, QR code authentication is provided.

With QR code authentication, users scan a QR code on the video wall with their mobile device and perform the authentication on their device. The actual authentication relies on either local password authentication or SAML authentication. After authentication on the device, a secret token is used to authenticate the user on the video wall.

QR code authentication is enabled by default in multi-user mode.

Session management

Canvus stores certain information on the user's device when they authenticate to improve the user experience.

  • When using Canvus desktop client:
    • When signing in to a Canvus Connect server, if the user enables \"Remember me\" option, a secret token and their username is stored in the operating system\'s secret store. This allows the user to authenticate to the server without having to re-enter their username or password.
    • If persistent browser sessions are enabled (the default), Canvus desktop client stores the user\'s browser session (cookies, history, etc.) inside Canvus on disk. This allows users to sign-in to web pages and not have to re-authenticate after they close the canvas or restart the Canvus desktop client. The browser sessions are unique to each user and are not shared with other web browsers installed on the same device running Canvus desktop client.
  • When using a web browser:
    • When signing in to a Canvus Connect server, if the user enables \"Remember me\" option, a cookie containing a user id and secret token is stored in the browser's cookie storage. This allows the user to authenticate to the server without having to re-enter their username or password.

The user\'s password is never stored on the device running Canvus client.

User credentials

When using local password authentication, user credentials are stored in a PostgreSQL database. The passwords are stored hashed in the database. The hashing algorithm is bcrypt.

When using only SAML authentication, no user credentials are stored in Canvus.

Forgotten passwords

When using local password authentication, users may reset their own password if they forget it. Passwords are reset by the server sending an email to the user's email address with a temporary link to reset their own password.

Administrator users can also reset or manually specify users' passwords.

End-user identification

User sign-up can be disabled for both local password authentication and SAML authentication. If disabled, all user accounts must be created by an administrator.

If sign-up is enabled, it is possible to enable administrator approval of all new user accounts.

Sign-up can also be further restricted by email address domain allow list. This restricts sign-up to only users with an email address in the allowed domain(s).