Using a Silverlight player with PlayReady and Token Authentication

Author: Christof Claessens –

Source code for this post is published at
You could test the token Silverlight Player to playback PlayReady Encrypted Smooth Streaming here:

Azure Media Services recently lighted up an exciting feature set related to Content Protection. More specifically, users have now the ability to protect their content with AES encryption or to leverage PlayReady. Both are enabled through a new key/licensing service, part of Azure Media Services.

We’ve written about how this works before and the documentation on MSDN should be pretty solid. What has not been completely clear so far though is the player side of the equation. For PlayReady however, the most convenient way to get started is to leverage Silverlight. The Silverlight Media Framework makes it very easy to get started playing Smooth Streaming protected with PlayReady. Except… in one case, which happens to be the scenario we’d expect most people to find themselves in for real production scenarios.

Allow me to explain.

The Silverlight Media Framework was conceptualized long before anyone was thinking about Azure Media Services or any of the Content Protection services we now feature. What it does when it gets handed a URL to a PlayReady protected stream is that it goes and reads the smooth streaming metadata and tries to fetch a PlayReady license from the license server.

The way you protect your media assets with PlayReady using the Azure Media Services Content Protection services is that you:

  • • Create a content key (which tells something about what key you want to use to encrypt stream with)
  • • Associate that content key with a media asset (which tells the service this is a key that can be used with this asset)
  • • Configure “Key Authorization Policy” (which configures the service under which conditions a key can be handed out by the key/license server)
  • • Configure “Asset Delivery Policy” (which tells Media Services something about the conditions in which streaming protocols will leverage which encryption type)

The Key Authorization Policy can specify following options:

  • • Open: a key will be handed out, regardless of who asks for it and where it comes from
  • • IP Restricted: this configures AMS in a way that a check will be made against an IP whitelist – if the request for a key doesn’t come from an IP in this list, the key request is refused
  • • Token Authentication

For both “Open” and “IP Restricted”, the Silverlight Media Framework as you know and love it today works just fine. (How could it not; it’s just a regular call to fetch a license – it doesn’t know if its IP address is being checked on the backend or not.) It’s for “Token Authentication” though that a slight modification is required to the player to make it play nice with the Azure Media Service license server.

The reason for this is that the token check that happens before handing out a license expects to find the token in the HTTPS Authorization header. This means that when making the HTTPS POST call to fetch a PlayReady license, the player should be aware it needs to add the Authorization header with the correct bearer token, signed with the symmetric key that has been configured in the key authorization policy.

Luckily, even though the Silverlight Media Framework was not developed yesterday, this is a scenario they architected for. In order to make it convenient for the community, we published the source code and instructions of how to do it:

Allow me, in order not to duplicate the entire sample here, to outline the high level approach.

In order to make it construct the Authorization header when fetching a license, the player framework calls into a so called “LicenseAcquirer”. This class can be subclassed to inject the header. Subclassing by itself though doesn’t instruct the player framework when to call into this new LicenseAcquirer. Remarkably enough, the forward-looking code however allows to override the LicenceAcquirer it needs to use, playlist item by playlist item. When your web page that hosts the Silverlight player constructs a playlist, it calls into “SetPlayList”. It’s at that point in time we can inspect the playlist items and determine for each of them if we want to override the LicenseAcquirer yes or no. Except… there’s no way to know if a bearer token needs to be injected just by inspecting the playlist item; it doesn’t contain any indication we should.

For that reason, the second small modification you can make is to extend the PlayListItem class with an additional “BearerToken” property, so you can construct your playlist in javascript and set the signed authorization token on the items that require it. The sample goes more in depth on how this can be done. (It is by no means the only way in which you could make this work, but it shows the basic principles of what is required here.)

From a JavaScript point of view, the experience of consuming this modified player should remain very straight forward:

With this: go and play with this yourself! We published the instructions, and the source code for you to look into and learn from. It’s remarkable how easy a PlayReady implementation has become once you can leverage the new Content Protection Service, all so you can go and focus on what makes you stand out instead, leveraging your precious time in a better way! If you have any questions, don’t hesitate to reach out to

Kind regards!

One Response to Using a Silverlight player with PlayReady and Token Authentication
  1. […] Using a Silverlight player with PlayReady and Token Authentication […]...

Leave a Reply

Your email address will not be published. Please enter your name, email and a comment.