Contact Support | System Status
Page Contents

    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: It’s More Than Just Security – It’s About Brand Integrity and Your Customer Commitments

    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
    Device registration Yes Yes
    Mid-stream restrictions check Yes 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
    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:

    • Anonymous - IP address of the client is not available
    • Public - Multiple users proxied from a location allowing public internet access
    • Corporate - Identify if multiple users are proxied through a central location or locations, and can share a single network-apparent IP address
    • Transparent - IP address of the client is available via HTTP headers, though the value is not necessarily reliable
    • Hosting

    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 the Ukraine and Korea, and add allow an IP address from Korea. Since Dylan’s content is public, every Playback Right needs to allow insecure access. When the Playback Rights are defined, Dylan will assign these to each media asset.

    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; only enabled or disabled

    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 account 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 account 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 account 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 account 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 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

      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 doesn’t require specific permissions (claims). It just needs to be signed with the customer’s 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.

    Page last updated on 13 Jul 2021