In this blog post we will cover the authentication XML as it is by far the number one question we get when it comes to testing the playback or setting up DRM license rights.
Below, we will investigate:
So, read carefully.
Back in the WMRM DRM days you were packaging your content with specific rights inside. Imagine that before distributing the content, you needed to define DRM license rights, package the content, distribute it and pray for your business model to stay the same and you wouldn’t need to re-package your whole library again.
We had to come up with implementations when customers could acquire a DRM license through so called License Acquisition Windows and in this case the DRM license was generated based on the profile that was created in the DRM providers web management console, for example. This added elasticity and solved the business model change problem.
It is good to know that new DRM schemes that first extended the WMRM DRM and then completely replaced it are more elastic and allow more dynamic DRM license rights definition and license acquisition process. But how do you define DRM license rights today?
There may be dozens of ways to do it. Each DRM provider is implementing its own. In KeyOS, we choose using a security token. It passed by the player to KeyOS MultiKey License Service.
The security token is authentication XML. The authentication XML is an XML data in a specific format which you generate on your server side. It is used by your player during a license request to the KeyOS MultiKey License Service.
Every player comes to the point when it needs a DRM license for the DRM protected content. Be that an HTML5 player, native Android/iOS player, STB player, Smart TV, Chromecast receiver – any player that knows how to playback the DRM protected content will come to a moment when it will need to request a license.
To receive a license from the KeyOS MultiKey License Service the player needs two things – license challenge and the authentication XML. The license challenge is generated automatically either by the CDM or the DRM agent, depending on what type of player is used. As for the authentication XML –generation is automated and provided into the player as a custom data.
The KeyOS MultiKey License Service expects the authentication XML to be passed inside the custom POST header with name “customdata”. Ways of setting this header on the player may differ depending on the player/platform you use.
Let’s see couple of quick examples of how different players/platforms allow you passing custom data in
In Roku, you can set the custom data using the following format:
The “customData” is where your authentication XML placed.
In dash.js HTML5 player, you don’t have a specific method to use, but you can set custom POST headers which will be passed during the license request:
As you can see, to pass the authentication XML using the custom header, all you need to do is set the header with name “customdata” and value of authentication XML. Last example with same idea in mind – requesting a license for the iOS AVPlayer by adding a custom data to the license request:
The request is made with custom header set which contains the authentication XML in it.
Now, let’s go over different cases of passing the authentication XML into your player in more detail.
Let's assume you have a website that contains video library. The end user logs into his library and selects a video to play. This is when you generate new Authentication XML, set up the player and render a web page for the end user to enjoy his video. This is the most common scenario, i.e., when the authentication XML is injected directly into the player.
The player will do the rest – generate the license challenge and send the request to the license service containing the custom data which is the authentication XML.
Figure 1. Direct authentication XML injection
Alternative way is where you may have a mobile application, or perhaps an app for your TV. You can't generate Authentication XML on the client, instead, your application request Authentication XML from your web server/API and place it in the player.
The player will do the rest – generate the license challenge and send the request to the license service containing the custom data which is the authentication XML.
Figure 2. Remote acquisition and injection
This method involves you setting up the license acquisition proxy on your server and pointing all your players to this proxy instead of pointing them directly to a KeyOS MultiKey License Service.
This method allows you more control over the license requesting made by the client. You can log license requests and responses which may come in handy during development process or issues during license acquisition. You also completely hide the fact that the authentication XML is required to acquire a license that adds. A remote proxy receives the original license challenge from the player, appends a POST header to it containing the Authentication XML, and forwards the license request with the authentication XML to the KeyOS MultiKey License Service. The KeyOS MultiKey License Service will respond with a DRM license (or an error) which the proxy then returns to the player.
Figure 3. Using proxy to get the license
Hopefully this post was helpful for you and you now know more about the authentication XML, why it is necessary to use it within the KeyOS MultiKey License Service, how to pass it into your players and other clients and ways to obtain it. You can always read more about the authentication XML, the structure, how to generate it and so on, in our Wiki. Please, do not hesitate to open support tickets, we are always here to help you.
See you next time.