Overview: Brightcove Playback Restrictions

In this topic, you will learn about different strategies for managing video playback by using Brightcove Playback Restrictions.

Introduction

Whether your content is for an internal or external audience, free or monetized, Brightcove Playback Restrictions provides the right level of content security to fit your use case while still allowing viewers to access the content from any device, anywhere.

This feature allows you to define different scenarios for streaming your content, including:

  • Where your content is available
  • How content is streamed
  • When content can be viewed
  • Who can watch your content

Check out the blogpost: Brightcove's Comprehensive Commitment to Video Security

Features

This feature's flexibility provides the ability to adapt to a number of different use cases.

Playback Restriction key features
Feature DRM required JWT required Playback Right required
IP restrictions No Yes
Country restrictions No Yes
Zip code restrictions No Yes
Designated Market Area (DMA) No Yes
Domain restrictions No Yes
Date/time scheduling No Yes
Recurring schedules No Yes
Proxy restrictions No Yes
Entitlement check No Yes
License Keys Protection Yes Yes
Stream concurrency Yes Yes
Generic stream concurrency Yes
Device registration Yes Yes
Mid-stream restrictions check Yes Yes
HDCP fallback Yes

Packages

Several security packages are available for Playback Restrictions.

Playback Restriction feature packages
Feature Security Tier 1 Security Tier 2 Security Tier 3
Geographic restrictions IP restrictions Yes Yes Yes
Country Yes Yes Yes
US ZIP Codes No Yes Yes
US DMA No Yes Yes
Domain restrictions Yes Yes Yes
Date/time scheduling Basic (start-end date) Yes Yes Yes
Recurring No Yes Yes
Proxy restrictions No Yes Yes
Entitlement check No Yes Yes
License Keys Protection No Yes Yes
HDCP Fallback No Yes Yes
Stream concurrency No No Yes
Generic Stream concurrency No No Yes
Device registration No No Yes
Mid-stream restrictions check No No Yes

Which products support Playback Restrictions?

The following Brightcove products support Playback Restrictions:

  • Video Cloud: VOD and Live
  • Virtual Events
  • Campaign
  • Engage
  • Gallery

How are Playback Restrictions applied?

Playback Restrictions can be applied as follows:

Asset-level restrictions

Asset-level restrictions are defined in Playback Rights.

You can use playback restrictions at the asset level when you want to restrict streaming for the following:

  • Region (Geo-restrictions)
  • Time (Scheduling)
  • Domain
  • Proxy type

Region

Geo-restrictions limit where your stream content can be viewed around the world. Options include:

  • IP addresses
  • CIDRs
  • Zip Codes (only available for US zip codes)
  • DMAs (only available for US DMAs)
  • Countries

TBD - Geo-restrictions have a global rule which defines the overall behavior as follows:

  • When the global rule is set to Allow All, it will allow all playback and you can blacklist regions.
  • When the global rule is set to Block All, it will block all playback and you can whitelist regions.

Time

Scheduling allows you to set an availability window to stream your content with two options:

  • Specific dates
  • Recurring for specific days and hours

Domain

Domain restrictions allow you to set domains where you want to allow or block streaming.

Proxy

Proxy restrictions prevent content streaming when a proxy is in place. There are five available proxy types (for details, see the table below the list):

  • anonymous
  • corporate
  • hosting
  • public
  • transparent
Playback Rights proxy properties
Field Type Description
blocked_proxies Object Properties related to proxy rights
blocked_proxies.anonymous Boolean IP address of the client is not available. Includes services that change location to beat DRM, TOR points, temporary proxies, and other masking services.
blocked_proxies.corporate Boolean Generally considered harmless, but location can be a concern. Identify if multiple users are proxied through a central location or locations, and can share a single network-apparent IP address.
blocked_proxies.hosting Boolean IP Address belongs to a hosting facility and is likely to be a proxy as end users are not typically located in a hosting facility.
blocked_proxies.public Boolean Multiple users proxied from a location allowing public internet access.
blocked_proxies.transparent Boolean IP address of the client is available via HTTP headers, though the value is not necessarily reliable (e.g., it can be spoofed).

Asset-level use cases

Use cases

Here are some possible use cases:

Limit content by zip code

  • Goal

    Shari (Web Producer at Sports League) wants to limit content access by zip code, so that viewers within the sporting event's zip code can not stream the event

  • Solution

    Shari can define Playback Rights to blacklist zip codes per region in the US. Since the content is public (there is no middleware application handling permissions), the Playback Rights need to be set as insecure. When the Playback Rights are defined, Shari will assign these to each media asset.

Limit content by country/IP address

  • Goal

    Dylan (CMO) wants to limit content access by country, so that viewers can stream from anywhere except Ukraine and Korea. Since the development team is located in Korea, Dylan needs to allow streaming from a specific IP address within Korea.

  • Solution

    Dylan can define a Playback Right to block Ukraine and Korea and allow an IP address from Korea. Since Dylan’s content is public, every Playback Right must allow insecure access. Dylan will assign these to each media asset when the Playback Rights are defined.

Setting asset-level restrictions

Playback Rights allow you to specify restrictions for video playback. These rights will be stored in the Playback Rights API and each set is assigned a unique id (playback_right_id). A set of rights can be associated with zero or more videos.

When a video has a playback_right_id, the restrictions specified in the Playback Rights object are applied to ALL requests for that video.

This diagram shows the flow from the user's video and license request to playback.

Playback Rights
Playback Rights

Asset-level restrictions can be defined by using either:

Using Brightcove APIs

You can use Brightcove's APIs to define asset-level restrictions. These steps can be used with Brightcove Player, the Native SDKs, or your own player.

  1. First, use the Playback Rights API to create a restriction.

  2. Then, use the CMS API to associate the restriction, with your video assets.

  3. For details, see the Implementing Playback Rights document.

Using Video Cloud Studio

You can also use Video Cloud Studio to define asset-level restrictions. These steps can be used with Brightcove Player or the Native SDKs.

  1. Expand the ADMIN dropdown menu, and select Playback Rights.

    Video Cloud Studio Admin
    Video Cloud Studio Admin
  2. For details, see the Managing Playback Rights document.

  3. Navigate to the Media module, and select the Name link for your video to see its details.

  4. Scroll down to the Playback Restrictions section and click the Edit button.

  5. Expand the dropdown menu, and select the restriction you want associated with this video.

    Media module restriction assignment
    Media module restriction assignment
  6. Select Save.
  7. Once you have defined your Playback Restrictions and associated them to videos, you are ready to configure your player.

    For details, see the Configure your player section of the Implementing Playback Rights document.

Notes

  • With Playback Rights, content does not need to be encrypted
  • By default, a valid token is needed to stream an asset with Playback Rights. But, you can set Playback Rights to not requre a token.
  • By default, all assets have a Playback Right that allows streaming to everyone, everywhere, any time
  • Each Video Cloud account has up to 100 Playback Rights
  • Playback Rights work with Video Cloud/CMS API restrictions (Country and Scheduling). CMS restrictions for an asset are validated before any Playback Rights
  • Playback Rights don’t work with Policy Key restrictions (Domain and Geo). When using Playback Rights with the web player or the Native SDKs, the Policy Key is removed. This means that restrictions set with the Policy Key will be ignored.
  • Playback Rights can’t be deleted in Studio; only enabled or disabled (they can be deleted using the Playback Rights API)

Runtime restrictions

To restrict streaming at runtime, you will need a JSON Web Token (JWT) with specific permissions (claims). This token is sent over every stream request.

This feature requires that you implement a middleware solution between your User Management System (UMS) and Brightcove's playback service.

The following restrictions can be set at runtime:

  • Playback Rights
  • Tags
  • List of content
  • Specific user-agent
  • Concurrent stream limit
  • Device limit

Playback Rights

You can either assign Playback Rights to an asset (see Asset-level restrictions), or you can set them at runtime using the prid claim.

Tags

At runtime, you can identify assets with specific tag values to be allowed for streaming. These tags are defined with the tags claim. You can group videos with tags using the Media Module in Brightcove's Video Cloud Studio.

The Playback Restrictions service will check the tags associated with each video. If at least one of the tags matches the list in the JWT token, then the video is viewable.

Tags in the JWT token will be listed as an array of tags.

List of content

Using the vids claim, you can specify, at runtime, a list of assets to allow for streaming.

Entitlement checks

An entitlement check sets end-user access rights at runtime based on video IDs and/or tags. This involves setting the following claims in the JWT:

  • prid
  • vids
  • tags

If a prid (Playback Rights ID) is set in the JWT, then the playback right for the asset will be overwritten.

Specific user-agent

To allow streaming from a specific user-agent, use the ua claim. To use this, your content needs to be encrypted, and you need to set an account flag which requires a JWT on licenses. Contact your Customer Success Manager to enable this account flag.

Concurrent stream limit

Limiting concurrent streams per user discourages viewers from sharing their credentials with friends who don’t have accounts. With concurrent stream limits, you define the number of video streams that a specific user can watch at any given time.

For this feature, the content needs to be encrypted DRM or HLSe.

For details, see the Limiting Concurrent Streams per Viewer document.

Device limit

At runtime, it is possible to limit the number of streaming devices for a user. For this, the content needs to be encrypted DRM or HLSe.

Device registration happens when a DRM license request is made, at which time a unique ID is assigned to each device. With each license request, the device limit is checked and enforced.

An example might be when the publisher must comply with the content owners’ requirements to limit the number of devices associated with a single viewer to 2 devices. After that limit is reached, if the viewer tries to stream the content on a third device, like a connected TV, playback will be denied. This feature enables content publishers to achieve monetization objectives and minimize unauthorized access.

For details, see the Implementing Device Limits document.

Runtime use cases

Use cases

Here are some possible use cases:

Allow paid access

  • Goal

    Liz (Event Planner) wants to only allow paid users access to an event's live and VOD content. She also wants to prevent link sharing.

  • Solution

    For this use case, every logged user who requests content from the platform needs to have a token with the following claims:

    • uid = "{unique user-id}"
    • climit = 1
    • cbeh = “BLOCK_NEW_USER”

    All content (live or VOD) needs to be encrypted with DRM.

    With these permissions, every logged user can stream live or VOD content as long as they are on the same device and network. If the user shares its platform credentials within the timeframe that the token is valid, another user trying to stream any content won’t be able to do it. With the feature's mid-stream checks, Liz can ensure this behavior for the entire content stream.

Block new streams

  • Goal

    Harry (OTT customer) wants to ensure that his platform users are able to view the content, but only one asset at a time.

  • Solution

    For Harry's use case, every logged user who requests content from his platform needs to have a valid token with the following claims

    • uid = "{unique user-id}"
    • climit = 1
    • cbeh = “BLOCK_NEW”

    All content (live or VOD) needs to be encrypted with DRM.

    The behavior for this case is similar to Liz's use case. The main difference is that Harry’s users won’t be able to watch different assets at the same time while the token is valid. With the feature's mid-stream checks every 5 mins, Harry can ensure this behavior.

Limit concurrent streams

  • Goal

    Shari (Web Producer at Sports League) wants to limit the concurrent streams to 1, for specific content.

  • Solution

    For this case, every logged user needs to have a token with the following claims:

    • uid = "{unique user-id}"
    • vids = ["asset 1","asset 2","asset 3"]
    • climit = 1
    • cbeh = “BLOCK_NEW”

Setting runtime restrictions

To use runtime restrictions, do the following:

  1. Implement middleware

    This feature requires that you implement a middleware solution between your User Management System (UMS) and Brightcove's playback service.

  2. Create a JWT

    Create a valid JSON Web Token (JWT signed with your private key) with specific permissions (claims). For details, see the Creating a JSON Web Token (JWT) document.

  3. Configure the player

    The token is passed with the playback request. If the token is invalid or expired, access to the content will be restricted. The player must be configured to use the token.

    Web player

    For details about configuring the Brightcove web player, see the Key/License Protection with Brightcove Player document.

    Native Android or iOS player

    For details about configuring the native player for Android or iOS, see the Key/License Protection with the Native SDKs document.

    Your own player

    If you are only using the JWT with your player, there is no extra configuration needed. If you are using Playback Rights with your player, then see the Configure your player section of the Implementing Playback Rights document.

Notes

  • To use the ua, maxip and maxu claims, you need the following:
    • Content needs to be encrypted
    • Your account needs to have JWTs required on License requests (License Keys Protection enabled). Contact your Customer Success Manager for details.
  • To use the climit and dlimit claims, you need the following:
    • Content needs to be encrypted with DRM
    • Your account needs to be enabled for CSL with the Check Rights flag enabled. Contact your Customer Success Manager for details.
  • Each token has an expiration, and it needs to be set when it is created. Your integrations are responsible for keeping the renewal process.
  • By default, mid-stream checks happen every 5 minutes.

License Keys Protection

License Keys Protection provides an extra level of security when delivering DRM-protected content with Dynamic Delivery. This is particularly useful for customers who want to control access to their content, and prevent unauthorized sharing of content.

DRM or HLSe content protection uses license/key requests, which can protect every stream request, with the use of a JSON Web Token (JWT).

Use case

You can use this feature when your content needs to be public but from a trusted request. For example, regional broadcasters with exclusive content encrypted with HLSe want to ensure that only requests from its platform are accessing the content. This means that viewers can only stream content from your platform. They will not be able to stream it outside of the platform, even with the stream URLs.

Enabling License Keys Protection

To configure your account for License Keys Protection, contact your Customer Success Manager to enable the License Keys Protection flag.

Using License Keys Protection

To use License Keys Protection, do the following:

  1. Implement middleware

    This feature requires that you implement a middleware solution between your User Management System (UMS) and Brightcove's playback service.

  2. Create a JWT

    With this feature enabled, every key or license request to decrypt the content needs a valid JSON Web Token (JWT signed with your private key). For details, see the Creating a JSON Web Token (JWT) document.

  3. Configure the player

    The token is passed with the playback request. If the token is invalid or expired, access to the content will be restricted. The player must be configured to use the token.

    Web player

    For details about configuring the Brightcove web player, see the Playback Restrictions with Brightcove Player document.

    Native Android or iOS player

    For details about configuring the native player for Android or iOS, see the Playback Restrictions with the Native SDKs document.

    Your own player

    To use the JWT with your player, there is no extra configuration needed.

Notes

  • This feature can be used without using Playback Rights.
  • The JWT token does not require specific permissions (claims). It just needs to be signed with the your private key.
  • Your content needs to be encrypted HLSe or DRM.

Limitations

The following limitations apply to this feature:

  • For HLSe (AES-128), the token will be appended to the master manifest request, and will propagate to the encryption key URL. Because these URLs are appended to the master manifest, customers should consider restricting the number of uses to minimize exposure of their content.
  • For HLSe (AES-128), players will make multiple requests when playing a video, typically one per rendition. The maxu claim needs to be set high enough to account for these requests. You should consider additional claims to minimize the exposure of your content. Switching renditions will request a new license.
  • Tracking of the maxu and maxip claims is eventually consistent. This means that if a token using these claims is reused many times in quick succession, it is possible to see that token accepted more times than those claims declare. The tracking becomes consistent within a few seconds and after that window the token will be blocked as expected.
  • Currently, Forensic Watermarking is not supported with License Keys Protection.