Introduction

Parts of Viz Mosart can be run with encrypted transport (HTTPS) and user sign-in (OpenID Connect). This chapter describes how the security layers of a Mosart installation fit together, how to choose an authentication mode, and how to set everything up: the identity provider, the certificates, the Mosart Web Apps and the Mosart servers.

The chapter has four sections:

• Choosing an Authentication Mode: default, API key or OIDC, and what each mode means for your integrations.

• Identity Provider and Certificates: what your IT department prepares and hands back.

• Securing the Mosart Server: HTTPS and OIDC on the main and backup Mosart servers.

• Password-Protected Features: the individually protected features that exist independently of HTTPS and OIDC.

What is secured, and by what

HTTPS and OIDC authentication secure the surfaces reachable from a browser or from another system: the Mosart Remote Controller Service, which serves the Mosart REST API and the SignalR hub, and the Mosart Web Apps with their proxy. These are the ways into a Mosart installation from outside the automation network, which is why authentication is implemented here first.

The rest of an installation is protected by other means:

• The Viz Mosart desktop applications, meaning AV Automation, Manus Administrator, Media Administrator and the Mosart GUI, run inside the automation network and are protected by that network's isolation, together with the password-protected features described in this chapter. They do not take part in OIDC sign-in.

• Links between Mosart components, such as Manus Administrator talking to the Remote Controller Service, use their own internal mechanisms rather than the OIDC path.

• Device and newsroom protocols, meaning MOS, GPI/O, and serial or TCP device control, follow the specification of each protocol and device. Where a device offers a secured connection, Viz Mosart can be configured to use it: the Generic REST driver, for example, supports HTTPS with a choice of authentication types.

How the layers fit together

In a full installation the browser, the proxy, the Web Apps server, the Mosart servers and the identity provider are all involved, and the settings are spread across them:

1. The browser signs in against the identity provider, through the Web Apps server, and receives a session cookie.

2. The Web Apps server reads the ID token to decide whether an app may open, and which controls that user sees.

3. For calls that reach a Mosart server, the app fetches the access token and sends it as a bearer token on REST, or as an access_token query parameter on the SignalR hub.

4. The Mosart server validates that access token against the same authority, and reads the role from it.

Security is therefore configured in two places, separately:

• The Mosart servers, main and backup, in Mosart central settings under Remote Controller Service > Security. Described in this chapter, under Securing the Mosart Server.

• The Mosart Web Apps, in the Web Apps Configuration Tool. Described in the Viz Mosart Web Apps Guide at the Vizrt Documentation Center, section Configuration Tool.

Enabling one without the other leaves you half secured, and some combinations do not work at all. Three rules apply throughout:

1. Authentication requires HTTPS. You cannot enable sign-in over plain HTTP.

2. Authentication requires your own certificate. The built-in certificate authority in the Mosart Web Proxy keeps the components behind it on plain HTTP, so the Configuration Tool only offers the Authentication section in custom certificate mode.

3. Mosart server settings need a service restart. Nothing under Remote Controller Service > Security takes effect until you restart the Mosart Remote Control Service, and you must do it on each server.

Roles across Viz Mosart

Roles are assigned in your identity provider, never in Viz Mosart. The role names are fixed by Vizrt. The groups you assign them to are yours.

In each pair, -admin grants full control and -viewer grants read-only access. What the identity provider must put in the token, and how to configure it, is described in Identity Provider and Certificates.

Setup at a glance

Four steps, in this order. The first two are usually done by your IT department, the last two in Viz Mosart.

The Web Apps half is configured in the Web Apps Configuration Tool and documented in the Viz Mosart Web Apps Guide at the Vizrt Documentation Center, section Configuration Tool. Three things there matter to the rest of this chapter:

1. In Server Configuration, HTTPS must use Custom certificate mode with your own certificate; the Authentication section only appears in that mode. Enter the Authority URL, Client ID and Client secret from step 1.

2. On the Studios page, confirm the Mosart main and backup server ports read 55168 once the Mosart servers are on HTTPS.

3. Add offline_access in the Scopes field. Without it an unattended screen, such as a Timing Display on the studio wall, ends up on a login page some hours after sign-in, once the session expires.

End to end verification

When all four steps are done:

1. Sign-in works. Open any Mosart web app. You are redirected to your identity provider and returned signed in.

2. The access token carries the roles. Do this before testing roles at all. Signed in, open the browser console and run:

   fetch('/auth/token').then(r => r.json()).then(d => console.log(JSON.parse(atob(d.accessToken.split('.')[1]))))

   Look for a flat "roles": [...] array, and check that aud matches the OIDC audience configured on the Mosart server. If the roles are missing here but the app opened correctly, they are in the ID token only. Fix that before going on.

3. A viewer can read but not write. As a user holding only mosart-viewer, the Named Overlays Editor opens read-only, and a direct write to the named overlays API returns 403.

4. An administrator can write. The same operation as mosart-admin succeeds.

5. Repeat against the backup server. It is configured separately, so test it separately.

Troubleshooting