Authorization in Flussonic via middleware¶
A very important task that should be addressed when starting the OTT IPTV service is the limiting access to streaming servers. According to our statistics, many people never pay attention to it, and, consequently, overpay for the traffic: their streams are simply stolen.
Video may be distributed to everyone, but should be cleverly encrypted; keys should be distributed indiscriminately, it is called DRM. Another method of protection is limiting distribution of the video itself; this is called authorization.
In Flussonic, a very flexible authorization scheme is implemented that requires certain actions by Middleware.
The scheme of work is as follows:
- The client console requests the stream URL
- Middleware provides a URL with a unique token
- Flussonic uses this token to identify the session
- Upon opening a session, Flussonic checks this token with middlware
Such a three-link scheme is needed to avoid embedding authorization into Flussonic. In turn, Flussonic sends a request to middleware only once in a while, rather than at each request from the client.
The issue of choosing the proper token remains unsolved, and we can offer a couple of methods of generating it.
The Share nothing token¶
The tokens may be generated to include all information that is necessary for authorization. For example, a token can be generated as follows:
token=sha1(secret_key + ip + stream_name)
After that, the token can be checked only if the secret_key is known. However, if an attacker tries to use this token, he will fail, since the IP will be different.
However, this token may be stored and used indefinitely. If a user has paid the subscription fee once, he may not pay again with this token.
Time may be inserted into the token:
time = utc()
token=sha1(secret_key + ip + stream_name + time)+":"+time
Now the middlware can check token age, and if it is more than one day old, it may be safely disabled. In practice, almost no one (except public TVs and fans of the Le Mans 24) is able to watch broadcasts for more than 24 hours in a row.
Tokens in the database¶
Authorization may be combined with accounting for viewing, and a new unique token may be created each time the used starts viewing, populating it into the database:
Later, in case of subsequent calls of flussonic to the middlware, the statistics for this session may be updated, storing the information about who watched videos and what volumes.