Viz Mosart Web Applications supports authentication using OpenID Connect. This page covers the Web Apps half of the setup: what to enter in the Configuration Tool, and the roles the web apps enforce.

Info: This configures the Web Apps half only. For the whole picture, including the identity provider requirements, securing the Mosart server itself, and the end-to-end verification, see the Viz Mosart Administrator Guide, chapter Security in Viz Mosart Ecosystem.

Prerequisites

  • HTTPS with a custom certificate has to be configured to use authentication; the Authentication section only appears in that mode. See the HTTPS and Certificates page.

  • You need a third party OpenID Connect authentication service, such as Keycloak, Okta, or Microsoft Entra ID. (If you are already using Vizrt's asset management system, Viz One, you should already have a Vizrt SSO Keycloak authentication server.)

Roles

Roles grant user permissions: what a user can do with the app. Roles are assigned in your authentication provider, not in the Configuration Tool, either to a single user or to all members of one or more groups. Role names are predefined and fixed by Vizrt, but you are free to define or reuse groups as you like. Each application reads them from the roles claim.

Showmaker

Role name

Permissions

showmaker-viewer

View only.

showmaker-admin

Full control.

Smart Panel

Role name

Permissions

smartpanel-viewer

Open and use panels, but not edit them.

smartpanel-admin

Full control, including creating and editing panels.

Named Overlays Editor

Role name

Permissions

mosart-viewer

View the overlay list and overlay properties.

mosart-admin

Create, edit, delete and import overlays.

Note: The Named Overlays Editor roles are mosart-admin and mosart-viewer. From Viz Mosart 5.16 with Mosart Web Apps 3.2, these roles are also enforced by the Mosart server on its Named Overlays REST API, so they gate the API as well as the editor UI. Earlier documentation used the names namedoverlays-admin and namedoverlays-viewer; those names are not read by any current version.

Note: Roles are only enforced when authentication is enabled. With authentication off, every user has full control. Assign roles before enabling authentication: a signed-in user with no role for an app gets an unauthorized-access screen, not a read-only view.

Info: The roles must reach the token as a flat, top-level claim named exactly roles, present in both the ID token and the access token. Keycloak needs a protocol mapper for this; its default nested realm_access.roles is not read. See Vizrt SSO (Keycloak) for a walkthrough, and the Viz Mosart Administrator Guide, chapter Security in Viz Mosart Ecosystem, for the details of which layer reads which token.

Setup

  1. Create a new Client/App registration according to your authentication provider guidelines:

    1. Keycloak guide

    2. Keycloak guide for Vizrt SSO

    3. Entra guide

    4. Okta guide

  2. Your authentication provider must provide the Issuer URL/Authority URL, the Client ID and the Client Secret.

  3. Open the Mosart Web Application Configuration Tool and select Server Configuration.

  4. Under the HTTPS section, enable the Authentication check-box and enter the details obtained at step 2.

  5. 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.

  6. Click Save. Authentication is now enabled.

Note: Enabling OIDC authentication on the Mosart server (a separate setting, on the server) switches off its REST API key, which affects integrations that call the Mosart REST API directly. Read Choosing an Authentication Mode in the Viz Mosart Administrator Guide, chapter Security in Viz Mosart Ecosystem, before enabling it in production.

Provider-specific newsroom authentication

iNEWS

Authentication will only work if you are using the NRCS plugin with the NRCS plugin iNEWS Client Addon. Authentication will not work by hosting the Plugin as a regular HTML plugin.

ENPS

To use the NRCS plugin with ENPS, first add your ENPS server machine to the list of allowed frame-ancestors in the Content Security Policy on your Authentication Provider.

Typically this is a simple edit of the Content Security Policy, from

frame-src 'self'; frame-ancestors 'self'; object-src 'none';

to

frame-src 'self'; frame-ancestors 'self' {Your ENPS server}; object-src 'none';

  • Keycloak: Go to Realm Settings > Security Defenses.

  • Okta: Follow this Okta guide.

  • Entra: Since you cannot edit the Content Security Policy for Microsoft Entra ID, authentication with Entra ID for the NRCS plugin in ENPS is not supported.

Octopus

NRCS plugin authentication is not currently supported with Octopus.