About participant authentication

Participant authentication via single sign-on (SSO) provides an additional, optional layer of security to prevent unauthorized access to meetings. It requires conference participants to authenticate via an Identity Provider service before they can join a Virtual Meeting Room or Virtual Auditorium, or access a Media Playback Service. It can be used instead of, or in combination with, conference PINs.

This topic covers:

Using SSO-based participant authentication

You can optionally require participants who are attempting to access a specific Virtual Meeting Room, Virtual Auditorium or Media Playback Service in your deployment to verify their identity using SSO before joining the meeting. The SSO service can also be used to provide a verified display name for meeting participants.

To enable SSO-based authentication, first you set up one or more Identity Providers, which are third-party services (such as ADFS, Microsoft Entra ID or Okta) that store and manage digital identities, and with which users authenticate using SSO. Then, you configure individual services to require that Hosts, Guests, or both authenticate with an Identity Provider to access the service.

SSO-based authentication is supported for participants joining via the latest versions of the Connect apps.

Participants joining from other devices (such SIP or H.323 endpoints) can optionally be permitted to join the meeting if the device is locally registered (i.e. registered to the same Pexip Infinity deployment that is hosting the VMR they are attempting to access), or manually admitted by a Connect app user.

You can optionally require participant authentication for meetings scheduled using Pexip's VMR Scheduling for Exchange feature. For more information, see Enabling Exchange Scheduling in single-use VMRs.

When is SSO not required?

In all cases, devices can join a meeting protected by SSO without needing to authenticate if:

Supported Identity Providers

Pexip Infinity can be configured with Identity Providers that support two widely-used standard industry protocols:

  • SAML 2.0
  • OpenID Connect (OIDC)

For more information about using SSO and Identity Providers with Pexip Infinity, see Using Identity Providers.

Supported Connect apps

The newer versions of the Connect apps support participant authentication. These are:

  • Connect web app from v27 and later
  • Connect desktop app from v1.9 and later
  • Connect mobile apps for iOS and Android from v1.9 and later.

Participants using older versions of the Connect apps cannot join VMRs with participant authentication enabled. Instead they will receive a message saying that their client does not support SSO-protected meetings, and suggesting they upgrade their client.

Participants using other versions of the Connect apps can still join the meeting if the VMR:

  • does not require participant authentication
  • requires participant authentication for Hosts only, and the participant is joining as a Guest
  • requires participant authentication for Guests only, and the participant is joining as a Host.

Note that all references to Connect app support also includes bespoke WebRTC clients using the Pexip client APIs.

Joining an SSO-protected VMR

To join a Virtual Meeting Room or Virtual Auditorium with participant authentication enabled, using a Connect app:

  1. Access the VMR in the usual way (e.g. by entering the room name, or via a Virtual Reception).
  2. If asked, select whether you are a Host or Guest, and enter the PIN (if required).

  3. Sign in with your Identity Provider:

    If your organization uses more than one Identity Provider, you see them all listed; choose the one you wish to authenticate with:

    The name that appears on each button in the pop-up is the Name for the Identity Provider that is configured on Pexip Infinity.

  4. If this is the first time you have used this Identity Provider, you are redirected to the Identity Provider where you must authenticate. This will usually be done via a new browser tab, which opens automatically. Otherwise, if you've already authenticated with the Identity Provider when accessing this or any other VMR, the authentication happens automatically using your previous credentials.

    Occasionally (at a period determined by the Identity Provider) your authentication session will expire and you will need to re-authenticate.

  5. After successfully authenticating, you go straight into the meeting.

Joining with other devices

If authentication is enabled for a VMR or Virtual Auditorium, you can also determine how to treat participants attempting to join from devices other than Connect apps, such as SIP or H.323 endpoints. You do this via the Other participants setting, where you have options to either put all such devices into a waiting room, or allow these devices to bypass the waiting room, but only if they are locally registered (i.e. registered to a Conferencing Node in the same deployment that is hosting the VMR or VA they are attempting to access).

Note that although Connect apps can be registered, the Other participants setting does not apply to them.

For each Virtual Meeting Room or Virtual Auditorium:

  • if Other participants is set to Allowed if trusted:

    • registered devices join the meeting directly (although they still need to enter a Host or Guest PIN if required)
    • unregistered devices are placed in the waiting room;

  • if Other participants is set to Disallow all:

    • both registered and unregistered devices are placed in the waiting room.

From the waiting room, participants must wait to be manually admitted to the conference by a meeting Host. Upon admission, they are not asked for a PIN and join as a Guest.

Authentication and PINs

VMRs and Virtual Auditoriums that require authentication can optionally use Host and Guest PINs.

For Connect app clients:

  • If PINs are configured:

    • Participants need to enter the PIN before authenticating.
    • The PIN that they enter determines whether they are a Host or a Guest, which then determines whether or not they need to authenticate, and if so, the Identity Providers to use.
    • A participant who joins as a Guest can subsequently be escalated to a Host without authentication.
  • If PINs are not configured, all users are treated as Hosts when authenticating.

For all other devices:

  • If PINs are configured, and the device is locally registered, and Other participants is set to Allowed if trusted, the participant must enter a PIN before joining the meeting.
  • If PINs are not configured, and the device is locally registered, and Other participants is set to Allowed if trusted, the participant joins the meeting automatically as a Host.
  • In all other cases, the participant is held in a waiting room and must wait to be admitted to the meeting by a Host. They are not asked for a PIN and will join as a Guest.

Transferring participants

Participants can be transferred from one VMR into another VMR that requires authentication.

For participants using a supported Connect app:

  • A participant can be transferred into a VMR that requires authentication only if the original VMR also required authentication and used the same Identity Provider as the destination VMR. The participant will not need to re-authenticate to join the destination VMR. If the original VMR did not require authentication, or the destination VMR uses a different identity provider, the transfer is not initiated and the participant remains in the original VMR.
  • A participant can be transferred from a VMR that requires authentication into a VMR that does not require authentication. From there, a participant can be transferred into a third VMR that requires authentication only if that VMR uses the same Identity Provider as the original VMR; the participant does not need to re-authenticate in order to join the third VMR. Otherwise, the transfer is not initiated and the participant remains in the second VMR.

For other devices, when a participant using a locally-registered endpoint is transferred, if Other participants is set to Allowed if trusted the participant will join the meeting directly (although they will still need to enter a Host or Guest PIN if required). In all other cases, for both registered and unregistered devices, the transfer will fail and the participant will remain in the original VMR.

Display names

Each Identity Provider offers a given set of attributes for a user (such as their display name, given name, surname and email address).

For Virtual Meeting Rooms and Virtual Auditoriums that require participant authentication, the name shown for each participant (in the participant list, and as a text overlay when Show names of participants is enabled) depends on what is configured in the display name setting for the associated Identity Provider, as follows:

For SAML Identity Providers, the relevant field is Display Name Attribute Name.

  • By default, the NameId attribute is used. This is the user's unique ID; what it contains depends on the Identity Provider.
  • To use an attribute other than NameId, enter it here. Note that the format used varies depending on the Identity Provider.
  • To use the name that participants entered themselves in their client, ensure this field is blank.

For OpenID Connect Identity Providers, the relevant field is Display Name Claim Name.

  • By default, the Name attribute is used. This is the user's unique ID; what it contains depends on the Identity Provider.
  • To use an attribute other than Name, enter it here. Note that the format used varies depending on the Identity Provider.
  • To use the name that participants entered themselves in their client, ensure this field is blank.

When the display name is based on information provided by the Identity Provider, it cannot be changed by the participant, the meeting Host, or via the client API. However, it can be changed via participant policy.

Viewing a participant's authentication status

Participants and administrators can view whether a participant was required to authenticate in order to join the meeting:

  • Meeting participants using Webapp3 can enable the option to Show authenticated participants.

  • Administrators using the Administrator interface can view the participant's status (Status > Participants) and scrolling down to the Authenticated by an Identity Provider field.