Skip to content

Showcase technical information

This document describes the architecture, network connections and security posture of MT Showcase. It is written for IT, network and information security teams who need to assess Showcase before it is installed on their network, and for administrators who operate it afterwards.

It applies to MT Showcase 26.09 and later, which uses the Node.js-based Showcase server introduced in 26.04. Earlier releases (1.x) used a different architecture; see Upgrading to 26.4.1 for what changed.

Replaces the earlier tech note

This page replaces the MT Showcase Architecture technical note (Rev 3, September 2017), which described MT Showcase 1.3 to 1.x. That note no longer reflects how Showcase is built or deployed.

Security defaults tightened in 26.09.6

MT Showcase 26.09.6 tightened several security defaults described on this page: first-time setup, password length, the control channel, the Windows firewall rule and log contents. Where behavior differs, this page says "From 26.09.6". If you run an earlier 26.x release, upgrade to the latest release; see the 26.x release notes.

At a glance

Topic Summary
Hosting model Self-hosted, on-premise. Showcase runs entirely on the customer's own application computer. No MultiTaction cloud service is required to run or author content.
Components Showcase player (native C++ application), Showcase server (Node.js), web-based Showcase Editor.
Supported platforms Ubuntu 24.04 LTS (x86-64), Windows 10 or later (x64), and macOS 13 (Ventura) or later on Apple Silicon (from 26.09.1).
Data storage Local SQLite databases and a local media library on the application computer.
Editor access HTTPS (TLS) on port 443 by default (8443 on macOS), from any modern web browser.
Authentication Per-user accounts with five roles, optional TOTP multi-factor authentication, optional SAML 2.0 or OpenID Connect single sign-on.
Password storage Argon2id hashes.
Default credentials None. The first administrator account is created in a setup wizard on the application computer.
Audit trail Security-relevant events are recorded and viewable by administrators.
Outbound internet Not required for day-to-day operation. Used for online license activation, crash reports and optional features; see External connections.

System architecture

Showcase uses a client-server architecture in which, in the standard deployment, every component runs on a single application computer that drives the display wall or touch screen.

flowchart LR
    subgraph AC["Application computer"]
        direction TB
        P["Showcase player<br/>(native application)"]
        S["Showcase server<br/>(Node.js)"]
        DB[("Application database<br/>(SQLite)")]
        RDB[("Reporting database<br/>(SQLite)")]
        M[("Media library<br/>and hosted sites")]
        P -- "control channel<br/>TCP 9299 (local)" --> S
        P -. "reads content" .-> DB
        P -. "reads media" .-> M
        S --> DB
        S --> RDB
        S --> M
    end
    D["Displays / touch screens"] --- P
    E["Showcase Editor<br/>(web browser)"] -- "HTTPS 443" --> S
Component Description
Showcase player A native C++ desktop application built on the MultiTaction Cornerstone SDK. It renders showcases on the connected displays and handles touch, marker (Codice) and gesture input. It includes an embedded Chromium-based web browser, which is started only when a showcase uses web content. The player does not accept incoming network connections.
Showcase server A Node.js application bundled with the installer (no separate Node.js installation is needed). It hosts the Showcase Editor and its REST and WebSocket API, manages the databases and media library, and serves the optional audience-facing pages.
Showcase Editor A browser-based authoring tool served by the Showcase server. Content authors and administrators use it from the application computer or from their own computers on the network. Nothing is installed on authors' computers.
Application database A SQLite database holding showcases, structures, themes, content sets, user accounts and settings.
Reporting database A SQLite database holding usage data collected by the Data Gathering service, if it is enabled in a showcase.
Media library Images, videos, PDFs and other files uploaded by authors, stored as files on the application computer's disk. Hosted sites and moderated audience uploads are stored alongside it.
Command-line tools showcase-server for administrative tasks such as creating an administrator or resetting a password, and mt-showcase-ctl for backup and restore. See Server CLI.

The player reads the application database and media library directly from the local disk. For this reason the player and the Showcase server are deployed on the same computer. The Showcase Editor, by contrast, is designed to be used remotely.

Connection diagram

The diagram below shows every network connection Showcase can make or accept. Solid lines are used in a standard deployment; dotted lines are optional features that are used only when configured.

flowchart LR
    subgraph LAN["Customer network"]
        A["Author / administrator<br/>web browser"]
        V["Visitor phones<br/>(audience features)"]
        subgraph AC["Application computer"]
            P["Showcase player"]
            S["Showcase server"]
        end
        IDP["Identity provider<br/>(SAML / OIDC)"]
        SMTP["Customer SMTP server"]
    end
    subgraph NET["Internet"]
        LS["MultiTaction license service"]
        DIAG["MultiTaction crash reporting"]
        WEB["Web content used<br/>in showcases"]
        EXT["External data sources"]
    end
    A -- "HTTPS 443 (inbound)" --> S
    V -. "HTTPS 443 (inbound)" .-> S
    P -- "TCP 9299 (local)" --> S
    S -. "SAML / OIDC" .-> IDP
    S -. "SMTP 587 / 465" .-> SMTP
    P -. "HTTPS (activation)" .-> LS
    P -. "HTTP / HTTPS" .-> DIAG
    P -. "HTTP / HTTPS" .-> WEB
    S -. "HTTPS" .-> EXT

Inbound ports

Port Protocol Listener Purpose Exposure
443 TCP (HTTPS) Showcase server Showcase Editor, REST and WebSocket API, audience pages and hosted sites. Open to the computers and devices that need to reach the Editor or audience pages.
80 TCP (HTTP) Showcase server From 26.10.0, redirects every request to the same address over HTTPS. Serves no content. On macOS the redirect is on port 8080. Optional. Open it only if users type http:// addresses. From 26.10.0 the Windows installer's firewall rule covers it.
8443 TCP (HTTPS) Showcase server The default port on macOS. On Ubuntu and Windows, used only if port 443 is already in use, or cannot be opened, on the computer when the server starts. As for 443 on Ubuntu. On Windows, from 26.09.6 the installer's firewall rule covers port 443 only, so a server that has fallen back to 8443 is not reachable from other computers until you add a firewall rule for it.
9299 TCP Showcase server Control channel between the Showcase player and the Showcase server. Local only. From 26.09.6 the server accepts control connections only from the application computer itself by default. See Hardening checklist.

When HTTPS is enabled (the default), the Editor and all content are served only on the HTTPS port. From 26.10.0 the server also listens on the plain-HTTP port (80, or 8080 on macOS) only to answer every request with a redirect to the same address over HTTPS; if that port is unavailable, the server starts without the redirect. Earlier releases did not listen on port 80, so users had to browse to https://<application-computer> (https://<application-computer>:8443 on macOS).

The ports and listening addresses can be changed with https_port, control_port and control_host in production_users.yaml, or with the equivalent SHOWCASE_* environment variables. See Settings reference and File locations.

Outbound connections

Showcase does not send usage analytics or telemetry to MultiTaction, and it does not check for or install updates automatically. The outbound connections it can make are:

Destination Protocol When it is used Can it be avoided?
ls2026.multitaction.com (MultiTaction license service) HTTPS 443 Online license activation and periodic license validation. Yes. Use offline license activation.
diagnostics.multitaction.com (MultiTaction crash reporting) HTTPS 443 on Windows; HTTP 80 on Ubuntu If the player or a Showcase tool crashes, a crash report (minidump) is uploaded to help MultiTaction diagnose the fault. Yes. Block it at the firewall; Showcase continues to run without it.
Customer SMTP server SMTP, typically 587 (STARTTLS) or 465 (TLS) Sending user invitations, password reset links and visitor emails. Yes. Email is optional.
MultiTaction email relay (Microsoft 365) SMTP 587 (STARTTLS) Only if email is used and no customer SMTP server has been configured. Messages are sent from no-reply@multitaction.com. Yes. Configure your own SMTP server in the Editor's email settings; we recommend this for all production installations.
Customer identity provider HTTPS SAML 2.0 or OpenID Connect sign-in, if single sign-on is configured. Yes. SSO is optional.
apps.multitaction.com HTTPS 443 Only when an administrator browses or imports MultiTaction demo apps. Yes. Demo apps are optional.
fonts.googleapis.com HTTPS 443 The Showcase Editor loads its user-interface fonts from Google Fonts in the author's browser. Yes. Without internet access the Editor falls back to system fonts.
Websites and web services chosen by authors HTTP / HTTPS Web pages shown in a showcase's web browser widget, favicon lookups for URL entries, and external data feeds or integrations configured by an administrator. Yes. These exist only if authors or administrators configure them.

Offline and restricted networks

Showcase can be operated without internet access. For an isolated or air-gapped installation:

  1. Activate the license using offline activation.
  2. Configure your own SMTP server, or do not use email features.
  3. Block or do not allow outbound access to diagnostics.multitaction.com.
  4. Do not use web content, demo app imports or external data sources that require the internet.

Data transmission and encryption

Showcase Editor and API. All traffic between web browsers and the Showcase server, including the Editor, the API, WebSocket live updates and audience pages, is carried over HTTPS. The server uses the TLS implementation of the bundled Node.js runtime, which accepts TLS 1.2 and TLS 1.3. From 26.09.6 the server also sends an HTTP Strict Transport Security (HSTS) header, so browsers keep using HTTPS for the server.

Control channel. The player and server communicate over a local TCP connection on port 9299. This channel is intended for communication within the application computer and is not encrypted or authenticated. From 26.09.6 the server listens for it only on the loopback address (control_host: 127.0.0.1) by default, so it is not reachable from the network. Earlier releases listened on all network interfaces; on those, set control_host: 127.0.0.1 as described in the Hardening checklist.

Email. Messages are sent using the security settings of the SMTP server you configure (TLS or STARTTLS).

Single sign-on. SAML and OpenID Connect exchanges use HTTPS and the security properties of your identity provider.

Certificates

HTTPS works out of the box. On first start the Showcase server generates a self-signed X.509 certificate (RSA 2048-bit, SHA-256) covering localhost, the computer's host name and its network IP addresses. The certificate is valid for 825 days and is regenerated automatically 14 days before it expires. On Ubuntu and Windows the installer adds this certificate to the application computer's trusted certificate store, so the local browser trusts it. On macOS the certificate is not trusted automatically; see Install on macOS. Browsers on other computers will show a warning until the certificate is trusted there.

For production use we recommend replacing the self-signed certificate with one issued by your own certificate authority. Administrators can upload a certificate and private key in PEM format in the Editor's Network Settings, or set tls_cert_path and tls_key_path in production_users.yaml. The private key file is stored readable only by the account that runs the Showcase server.

Authentication

First-time setup

Showcase has no default user name or password. Until the first administrator account exists, the server offers only the setup wizard; the Editor and API are not available.

From 26.09.6, the setup wizard can be completed only in a web browser on the application computer itself. Setup requests from other computers are refused, so no one else on the network can create the first administrator account. For an installation without a local display (headless), an administrator can set setup_allow_remote: true in production_users.yaml and restart the Showcase server to allow setup from another computer; remove the setting again once setup is complete. In earlier releases the wizard could be completed from any computer that could reach the server, so complete setup before the computer is placed on a shared network.

If administrator access is lost, a new administrator can be created, and passwords reset or accounts unlocked, with the showcase-server command-line tool. This requires local administrative access to the application computer. See Server CLI.

Sign-in methods

  • Local accounts. Users sign in with an email address and password stored in the application database.
  • Single sign-on. Showcase can authenticate users with any SAML 2.0 or OpenID Connect identity provider, such as Microsoft Entra ID, Okta, Auth0 or Google. When SSO is used, passwords are handled by the identity provider and not stored by Showcase.
  • Multi-factor authentication. Users can enroll a time-based one-time password (TOTP) authenticator app. Administrators can require multi-factor authentication.

See Users and security for configuration.

Credentials and sessions

  • Passwords are stored only as Argon2id hashes, never in plain text. Sign-in takes the same time whether or not the email address exists, so the sign-in form cannot be used to discover accounts.
  • From 26.09.6, passwords must be at least 12 characters long. Following NIST SP 800-63B, Showcase does not require particular character types such as digits or symbols. The minimum applies whenever a password is set or reset; existing shorter passwords keep working until they are changed, so ask users with short passwords to change them after upgrading. Where your organization has its own password policy, use single sign-on so the policy is applied by your identity provider.
  • After 5 failed sign-in attempts within 15 minutes an account is locked for 15 minutes. Administrators can change these thresholds.
  • A successful sign-in issues a short-lived access token (15 minutes) held in the browser's memory, and a refresh token stored in an HttpOnly, Secure, SameSite=Strict cookie. Refresh tokens last 30 days, are replaced every time they are used, and are revoked in full if an old token is ever reused.
  • Signing out revokes the session on the server.
  • Invitation links expire after 7 days and password reset links after 30 minutes.

Access control

Every Editor and API action is checked against the signed-in user's role.

Role Access
Administrator Full access, including user management, security, network and email settings, and the audit log.
Author Create, edit and publish showcases, themes, structures, content and media.
Presenter Open and present existing showcases.
Front desk Can update the text shown in text widgets, without access to other content or settings.
Viewer Lowest level of access; cannot change content.

Visitors using audience features do not receive an Editor account. They can reach only the specific pages described in Audience-facing features.

Audience-facing features

Showcase includes optional features that let visitors interact with a showcase from their own phones. Phones connect directly to the Showcase server over HTTPS; there is no MultiTaction cloud service or relay in between. To use these features, the Showcase server must be reachable from the network the phones use (for example venue Wi-Fi), and an administrator sets the address phones should use in Network Settings.

  • Visitor uploads. A visitor scans a QR code to open an upload page. Each QR code carries a random token that expires after 10 minutes and allows up to 10 uploads. Only JPEG, PNG, WebP and MP4 files up to 10 MB are accepted, with per-address rate limits. Uploads are held in quarantine until a moderator approves them in the Editor; rejected uploads are deleted automatically after 30 days.
  • Personal folders. Visitors can open their own personal folder from a QR code, for example on a printed card or shown on the wall. The QR code is a persistent link that stays valid until an operator resets it, so reset a person's link if a card is lost or the folder should no longer be reachable. From the folder page, visitors can view and download their files, edit the details an administrator allows, and upload files, which are held for moderation like other visitor uploads. Links are stored encrypted, as described under Data storage and protection.
  • Hosted sites. Administrators can publish web bundles that Showcase serves at /www/<site>/ without sign-in. Hosted sites are served with a restrictive sandbox content security policy that isolates them from the Editor, and uploaded bundles are validated to prevent path traversal. Only publish content you intend to be public to anyone who can reach the server.
  • Email from the wall. Visitors can email items from a showcase to an address they enter. Messages are sent through the configured SMTP server.
  • Browser player (Beta). The browser player at /player/ runs apps in a web browser. From 26.10.0 it works without sign-in by default, as in Showcase 1.14: anyone who can reach the server can read the app list, structures and widget settings and play media files. PIN codes and passwords are never returned. Set public_browser_player: false to require a sign-in; the browser player then cannot load. See Server settings: Browser player.

If you do not use these features, you do not need to make the Showcase server reachable from visitor networks.

Data storage and protection

All Showcase data is stored on the application computer.

Data Ubuntu Windows macOS
Application database /var/lib/mt-showcase-server/showcase.db %APPDATA%\mt-showcase-server\showcase.db ~/.mt-showcase/showcase.db
Reporting database /var/lib/mt-showcase-server/showcase-reporting.db %APPDATA%\mt-showcase-server\showcase-reporting.db ~/.mt-showcase/showcase-reporting.db
Media library /var/lib/mt-showcase-server/assets %APPDATA%\mt-showcase-server\assets ~/.mt-showcase/data
Hosted sites /var/lib/mt-showcase-server/sites %APPDATA%\mt-showcase-server\sites ~/.mt-showcase/sites
Backups /var/lib/mt-showcase-server/backups %LOCALAPPDATA%\MultiTaction\showcase\backups ~/.mt-showcase/backups
TLS certificate /var/lib/mt-showcase-server/certs %PROGRAMDATA%\mt-showcase-server\certs ~/.mt-showcase/certs
Server settings you can edit /etc/MultiTaction/mt-showcase/server/production_users.yaml <install folder>\server\production_users.yaml /etc/MultiTaction/mt-showcase/server/production_users.yaml

On Ubuntu, the data directory belongs to a dedicated mt-showcase-server system account and is not readable by other users (mode 0750). On Windows, data is stored in the profile of the user account that runs Showcase, and on macOS in the home folder of the user who runs it. See File locations for the full list.

Secrets. Sensitive settings, including token signing keys, multi-factor authentication secrets, single sign-on configuration, persistent personal folder links and SMTP passwords entered in the Editor, are encrypted with AES-256-GCM. The encryption key is generated per installation and stored in a file readable only by the Showcase server account, or it can be supplied through the SHOWCASE_AUTH_KEK environment variable. An SMTP password written directly into production_users.yaml is stored as plain text, so prefer entering it in the Editor.

Encryption at rest. Showcase does not encrypt the databases or media library itself. Where content is sensitive, use full-disk encryption on the application computer, such as BitLocker on Windows or LUKS on Ubuntu, and protect backup files accordingly.

Personal data and privacy

Showcase is operated by the customer, who acts as the controller of any personal data it holds. MultiTaction does not receive this data.

Depending on the features used, Showcase may process:

  • Editor users: name, email address, role, sign-in history and audit events.
  • Visitors: names and email addresses entered at the wall or in a personal folder, and photos or videos they upload.
  • Usage data: if a showcase uses the Data Gathering service, interaction data such as touches, content views, sessions and marker (Codice) events, stored in the local reporting database. Where visitors identify themselves with a marker, their name and email address can be linked to that marker's activity. Administrators can view and export this data as CSV from the Editor.

Personal data stays on the application computer unless an administrator exports it or emails are sent. Records such as users, personal folders, markers and media can be deleted from the Editor. Apart from rejected uploads (deleted after 30 days) and archived hosted sites that are no longer used (removed after 7 days), Showcase keeps data until it is deleted, so define a retention practice suitable for your organization.

Crash reports sent to MultiTaction contain a snapshot of the crashed program's memory, which could include content that was on screen at the time. Block crash reporting if this is not acceptable in your environment.

Audit trail and logging

Showcase records an audit trail of security-relevant events, including successful and failed sign-ins, account lockouts, refresh-token reuse, denied WebSocket connections and administrative changes such as user and role management. Administrators can view the audit trail in the Editor.

The Showcase server and player also write operational logs:

  • Ubuntu: the mt-showcase-server systemd journal (journalctl -u mt-showcase-server) and log files under the service account's MultiTaction/showcase/logs folder.
  • Windows: %PROGRAMDATA%\MultiTaction\showcase\logs.
  • macOS: ~/.mt-showcase/showcase.log, and log files under ~/MultiTaction/showcase/logs.

Logs may contain request paths and IP addresses. From 26.09.6, query strings are removed from logged request URLs, so the access codes carried in audience and personal folder links are not written to the logs. Rotate or forward logs according to your logging policy.

Operating system integration

Ubuntu

  • Installed as a Debian package under /opt/mt-showcase-<version>/. Only one version of Showcase can be installed at a time: installing a different version removes the installed one, and installing 26.x removes Showcase 1.x.
  • The Showcase server runs as the mt-showcase-server systemd service under a dedicated, non-login system account, and restarts automatically if it stops. authbind allows this unprivileged account to use ports 80 and 443; the service does not run as root.
  • The package installs an AppArmor profile for MultiTaction applications. Its purpose is to allow the user-namespace sandbox used by the embedded Chromium browser on current Ubuntu releases.
  • The self-signed certificate is added to the system certificate store.
  • The package does not change firewall (ufw) rules.

Windows

  • Installed with an installer that requires administrator rights, into C:\Program Files\MT Showcase. It also installs the Microsoft Visual C++ runtime.
  • The Showcase server starts at sign-in as the MT Showcase Editor scheduled task. It runs as the signed-in user with standard (least) privileges, not as a system service. The server is not restarted automatically if it stops; it starts again at the next sign-in, or an administrator can start it manually as described in Start and stop.
  • The installer adds an inbound Windows Firewall rule, MT Showcase Editor Service, that allows inbound TCP port 443 (and, from 26.10.0, port 80 for the HTTPS redirect) to the bundled Node.js runtime, and trusts the self-signed certificate in the local machine's certificate store. Both are removed when Showcase is uninstalled. The rule is limited to port 443 from 26.09.6; installers of earlier releases allowed the Node.js runtime on every port.
  • Crash dumps are also kept locally in %LOCALAPPDATA%\CrashDumps.

macOS

  • Distributed as a signed and notarized application bundle, installed by dragging it to /Applications/MT Showcase.app. No additional software is installed.
  • Starting the app starts both the Showcase server and the player, as the signed-in user. There is no separate system service.
  • The server listens for the Editor on port 8443 on all network interfaces. The control channel on port 9299 listens only on the loopback address.
  • The self-signed certificate is not added to the system trust store; an administrator can trust it manually.
  • If the macOS firewall is on, macOS asks whether to allow incoming connections for Showcase.

Backup, updates and maintenance

  • Backup and restore. On Ubuntu and Windows, mt-showcase-ctl --backup and --restore back up and restore the application database, reporting database and media library, and from 26.10.0 the encryption key .auth-kek. On macOS, back up by copying the data folder while the server is stopped. Installing a new Showcase version does not back up your data, so create a backup and copy it off the application computer before every upgrade. See Backup and restore and Upgrade.
  • Updates. Showcase does not update itself. Administrators download new versions from the Showcase downloads page and install them when convenient. Security-relevant changes are listed in the release notes.
  • Signing keys. Administrators can rotate the token signing keys with showcase-server keys:rotate-signing. Existing sessions remain valid during a changeover period.

Hardening checklist

We recommend the following for production installations:

  1. Run a current release. Several defaults below were tightened in 26.09.6; upgrade installations running an earlier 26.x release.
  2. Complete the setup wizard on the application computer immediately after installation. From 26.09.6 remote setup is refused by default. If you enable setup_allow_remote for a headless installation, complete setup before the computer is connected to a shared network, then remove the setting.
  3. Keep the control port local. Leave control_host at its default of 127.0.0.1 (the default from 26.09.6), so port 9299 accepts only local connections, and do not allow port 9299 through the firewall. Change control_host only if your deployment requires it, and firewall port 9299 if you do. On releases before 26.09.6, set control_host: 127.0.0.1 in production_users.yaml explicitly and, on Windows, add a firewall rule blocking inbound TCP 9299.
  4. Restrict port 443 to the networks that need it: author workstations and, if audience features are used, the visitor network.
  5. Install a CA-issued certificate in place of the self-signed certificate.
  6. Use single sign-on where available, or require multi-factor authentication for administrators and authors.
  7. Apply least privilege. Give each user the lowest role that meets their needs and remove accounts that are no longer required.
  8. Configure your own SMTP server. For production use, send email through your organization's SMTP server rather than the built-in MultiTaction relay, and enter the SMTP password in the Editor rather than in the configuration file.
  9. Turn off the public browser player if you do not use it. Set public_browser_player: false in production_users.yaml so apps and media cannot be read without a sign-in. See Browser player.
  10. Disable audience features if you do not use them. Setting integrations_enabled: false in production_users.yaml turns off hosted sites, personal folders, visitor uploads and external integrations entirely. If you do use them, review hosted sites before publishing.
  11. Encrypt the disk of the application computer and protect backup files. From 26.10.0 a backup includes the installation's encryption key, .auth-kek, so anyone with a backup can read the secrets stored in it.
  12. Control outbound access. Allow only the destinations in Outbound connections that you need.
  13. Review the audit trail regularly.
  14. Restrict operating system access to the application computer; local administrators can create Showcase administrator accounts from the command line.