How do I secure video in different use cases?

Overview

Vidyard offers an ability to secure videos so that only the people that you intend to watch the content, will have access to it. 

This article will cover six security features for a Players/Videos that are available in Vidyard when you have access to the full Platform (Vidyard customers, including GoVideo Enterprise users). You can use the examples below to match to your use case. 

The features discussed are:

• IP Whitelisting
• Sharing Pages switched OFF
• Single Sign On (SSO) for Hubs and Sharing Pages
• JSON Web Tokens
• Video Hub 'Manual' Log In System
• Access Codes
• Domain Restriction (aka Domain Whitelist)

The use cases below will attempt to match popular business scenarios and provide recommendations to secure your content.

1. Intranet (internal only) with no SSO

2. SSO based intranet/CMS (internal only)

3. Portal-based system for internal and external use

4. Video Hub for Internal employees or restricted access.

5. Individual Players shared externally (1 to 1)

Use Cases

1. Intranet (internal only) with no SSO

Scenario

You have an intranet system for internal employees and wish to embed players onto pages using the inline Javascript code. Employees outside of the office need to use VPN to access this intranet system. There are no other ways to access this content.

Solution

For this use case, there is no requirement to have Sharing Pages. IP detection will ensure that only the employees within the company network can access the video content.

• Sharing Pages switched OFF
  Turning sharing pages off will ensure that the only place to access the player would be via the Javascript or via the source of the player's iframe (play.vidyard.com/*UUID*)
• IP Whitelisting
  Due to the intranet only being accessible inside the office or via VPN, you can ask your IT Team to provide a list of IP ranges that the company use. These can be placed on individual players, or over whole group.
  
  If a player is accessed by someone outside of the organization, it will not show the video content. IP Whitelisting will also ensure that if the play.vidyard.com/*UUID* address is leaked, the content is still only accessible via your company's IP Range.

2. SSO based intranet/CMS (internal only)

Scenario

Your intranet/CMS system is accessible by your employees by logging into a SAML based SSO system such as Azure AD, OKTA, Salesforce and Google (amongst others). The ranges of IP being used to access the system are vast (too many/impossible to list). The players are displayed inline.

Solution

For this use case, you will need to consider setting up SSO for your sharing pages and set Restrict to secure platforms for each player.

• SSO for Sharing Pages
  Based on the need to sign in to the iDP prior to accessing the intranet>CMS, the best method to protect access is to require the same style of sign in for your players. Due to having logged into the system, the Javascript players will display the content. If these players are embedded onto external websites by mistake, then the content will only show if you are signed into iDP.

3. Portal-based system for internal and external use

Scenario

Your system is designed to allow internal and external clients to use it. Due to this, IP whitelisting or SSO is not possible. In this case, it's best to have a mechanism on the page to authorize the viewer into the player and a way to stop the Javascript code being embedded on other sites.

Solution

• JSON Web Tokens
  Setting up JSON Web Tokens will ensure that the Player only loads after the page can identify that the viewer has passed through the security of the portal correctly.
• Domain Restriction
  Having a Domain Restriction will ensure that if the embed code is copied from your page (this can be done by looking at the HTML in the page source) and embedded elsewhere, then it will not load the videos outside of the domain set.
  For instance, one of your external users could attempt to pull out paid content and place the javascript on their own website. The Domain Restriction will show an error if the video content is attempting to be played on a domain that isn't in the list set.
  
  Note: Domains can be 'spoofed' on local machines, meaning someone can set up a server on a personal network and pretend that the domain is the one being used on your secure site. Therefore do not treat Domain Restriction as a secure method of embedding content, but a way to stop the player being able to be placed on the internet elsewhere (such as an illegal site) and being accessible.
   

4. Video Hub for Internal employees or restricted access

Scenario

You use a Vidyard Video Hub to make it easy to show all of your groups content (either through tags or fixed selection). As some of the Video Hub's content is for internal eyes only, you require a method to stop external parties watching the content.

Solution A (SSO available, internal only)

• SSO for Hubs
  Securing your hub with SSO will ensure that if any of the hub's pages are loaded in the browser, a redirect to your iDP login page will show before being able to proceed. If you user has already logged in, then the experience is seamless.

Solution B (No SSO or some external users required)

• Video Hub Manual Login
  You can use the Vidyard Manage Users 'Manually' option on the Video Hub security page to force a login to the hub before accessing the content. You could in theory also provide access to external users via this method.

For both solutions, ensure that the 'Restrict to Secure Platforms' is checked on the confidential players. You can also disable Sharing Pages for these particular players, as the video content will not be delivered to them.

5. Individual Players shared externally (1 to 1)

Scenario

You have a confidential video you would like to share to someone, but they are external to your SSO system or IP range, then providing an access code will be the most suitable method.

Solution

• Access Code
  Generating an Access code for a player will provide a method to ensure that the content can only be watched a limited number of times, and only by the person/people that you provide the code to. For example, you could provide a link to your sharing page via email and then place a phone call to tell them what the access code is.
  
  

If you have a use case that isn't listed here, feel free to let your CSM know. They will be happy to advise you.