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. Select the Authentication (OIDC) check-box and enter the details obtained at step 2. The check-box is described as "OpenID Connect allows this app to provide secure sign-in and verify your identity details." It appears only while the certificate mode is Custom certificate, so with the built-in CA there is no authentication section to enable.

  5. Optionally add offline_access to the Scopes field. Scopes is a space-separated list of scopes requested in addition to openid, profile and email, which are always sent, so to add this one the field contains just offline_access.

  6. Decide how long a signed-in session lasts, and which apps it applies to, using Session timeout and Allow session timeout in the same block, below Scopes. See Session timeout below.

  7. Click Save. Authentication is now enabled.

Info: What offline_access is for. It requests a refresh token from your identity provider, which lets the web apps renew the access token they present to the Viz Mosart server. Without it, an app that has been open for a long time eventually cannot reach the Mosart server any more. It has nothing to do with how long you stay signed in to the web apps themselves: that is the Session timeout setting, and renewing a Web Apps session reissues the existing sign-in locally without contacting the identity provider.

Info: On a first-run installation the same settings are collected by the Quick setup wizard. Choose Secure with HTTPS on the Access step, then Custom certificate on the Security step, and a Require sign-in (OpenID Connect) toggle appears with Issuer URL, Client ID, Secret and Scopes (optional). The review step warns Sign-in won't be enforced if a configuration arrives with OIDC on but no custom certificate, which is the state to watch for when carrying settings over from another machine.

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.

Session timeout

With authentication enabled, a signed-in session ends after a period without use and the user has to sign in again. Both how long that takes, and which apps it applies to, are configurable. Both controls are in Server Configuration, in the block that appears below Scopes once Authentication (OIDC) is selected.

Session timeout is how long an unused session survives, in minutes. The default is 30, and the permitted range is 5 minutes to 10080 minutes, that is one week. A value outside the range is clamped to the nearest limit, and one that is not a whole number falls back to 30; either case is written to the server log at startup.

Allow session timeout carries one switch per web app, with a line above it counting how many are switched on, for example 3 of 7 apps can time out when idle. A switched-on app reads Renews while in use; can time out when idle. A switched-off app reads Stays signed in while open, and keeps its session alive for as long as its page is open, whether or not anyone is at it.

The defaults are chosen so that nothing on air is signed out mid-show:

Can time out when idle

Stays signed in while open

Showmaker
Template Editor
Named Overlays Editor

Smart Panel
Prompter
Rundown Viewer
NRCS Plugin

Note: An app that is not listed in the configuration at all defaults to timing out. That is the safe direction for an app added in a future release, but it means a hand-edited configuration file can leave a surface you expected to stay signed in timing out instead. Check the switches rather than the file.

Before the session ends

The window is an idle window: it runs from the user's last activity, not from when the page was loaded or last renewed. Typing, clicking, scrolling, the scroll wheel, moving the mouse, touch and any text input all count.

Where an app embeds a panel from another product, such as Viz Pilot Edge, that panel's own events cannot be seen from the host page. Having the focus in it therefore counts as activity for up to five minutes, and anything the panel sends back, such as an item dropped into a story, counts in full and starts the window again.

Ninety seconds before the session would end, an app that can time out shows a dialog headed You will be logged out soon, reading "For your security, we log you out automatically when you have not been active for a certain period of time.", with a live countdown that turns urgent for the last thirty seconds.

  • Continue session buys a fresh full window and returns the user to what they were doing. Nothing reloads and nothing is lost.

  • Log out now ends the session immediately.

If the countdown runs out, the app shows Session timeout! with a Login button.

Info: The countdown comes from the server rather than the browser's own clock, because a machine that has been asleep, or a tab the browser has throttled in the background, cannot be trusted to have counted correctly. This is also why a laptop reopened after a long sleep goes straight to the expired dialog rather than showing a warning first.

Note: Renewal reissues the existing sign-in without contacting the identity provider. The session timeout therefore also bounds how long a disabled account, or a changed set of roles, keeps working in the web apps. Shorten it if your organisation expects a revoked account to lose access promptly.

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.