RTMP Authentication- client support

Hi all,

I’m currently working up a proof-of-concept secure streaming solution using Wowza- my institution currently uses FMS, but implementing any sort of security on that platform has proven far too difficult.

I’ve so far managed to install the media security plugin, and successfully stream encrypted video over RTMP using the SecureToken feature. My next step is to set up username/password authentication for clients connecting to the server- my research indicates that this is not a common security measure, but it’s non-negotiable for us because we want to start delivering sensitive media such as surgery videos, where the patient’s privacy needs protecting.

The security plugin appears to provide server-side support for authentication in a very sensible fashion, but I’m having trouble finding client software which will interact with this out of the box- it seems that this functionality is mainly implemented by encoders such as FMLE, rather than video players. I’m currently using JW Player 5.9, recompiled to include secure token. I’m willing to write custom front-end code to support authentication, but as I am not a flash developer and dislike working with AS, I’d rather avoid it if at all possible.

Does anyone know of front-end video player implementations which support username/password auth out of the box? If not, are there any suggestions for the easiest way to implement this myself?

Thanks in advance,

Alex

You could use these module with any player by adding querystring param to connection string:

https://www.wowza.com/docs/how-to-do-file-based-rtmp-authentication-with-url-query-strings-onconnectauthenticate2

https://www.wowza.com/docs/how-to-do-user-authentication-for-flash-rtmp-client-using-jdbc-connection-to-mysql-database

Richard

I don’t think you can hide or encrypt the connection string

Richard

With Flash RTMP clients using SecureToken/RTMPE and HotlinkDenial Addon, you can be sure that users are using your player to view your content and that they can’t download the content. To authenticate them, you have to pass credentials somehow.

You might authentication before streaming over HTTPS, then set a cookie, then grab the cookie in Flash and pass it to Wowza with NetConnection.connect or NetStream.play. You can use ExternalInterface in Flash to get a cookie from the HTML container. The cookie could be specially formed for re-authentication of some kind. Some customers have done time based tokens/cookie, that expire.

Richard

You’re welcome. Thanks for the update

Richard

Thanks, that’s very helpful. I’ll use this solution for now, as in the first instance we’re only going to be authenticating a small group of users and can simply put their usernames and passwords into a file on the server.

However, I’m interested to know if there is any way of securing the connection string itself. In the longer term we want to provide authentication for tens of thousands of users against an existing identity service, and as such we can’t really get away with sending their credentials in clear-text in the RTMP request- the security guys would flay me! :wink: Do you know if there are established methods for sending the authentication request over an encrypted connection, perhaps tunneling it over https or something?

Thanks again for your help, it’s much appreciated.

Fair enough, I had sort of expected that.

I get the feeling I’m barking up the wrong tree here with username/password auth- what do the big commercial content providers do to ensure that only the right users have access to their media? I more or less have the same requirements as them, except that instead of trying to protect profit margins I’m trying to protect the institution from legal problems.

Cheers Richard, this is all very helpful. I’ve come up with a method of passing credentials securely by RSA public-key encrypting them before passing them to the server, and rolling a modified version of the OnConnectAuthenticate2 module which decrypts the creds on the back-end and validates them, but a token approach is probably a safer idea so I’ll go for that in the longer term.

Thanks again for all your assistance.