RTMP & Flash Media Streaming Server Live application

[teh_chicken]

I'm running Flash Media Streaming Server and have only been serving VOD up until now.  I had my network administrator open up port 1935 to the outside world during the setup process and now I can't remember if that was actually required for streaming VOD to clients.  Most documentation I've read says that this port should be open, but I seem to recall reading something at one point that suggested it wasn't necessary.

I've just started messing around with publishing live streams using Flash Media Live Encoder to the Flash Media Streaming Server.  I have that working without issue but was surprised to find that no authentication is required before a client running the live encoder can publish a stream to the Flash Media Streaming Server.  An authentication module is available however it only works with Flash Media Interactive Server and Flash Media Development Server.

If I leave port 1935 open to the outside world, there would be nothing to stop anybody anywhere from streaming video via my server.  Anyone else running a default install of Flash Media Streaming Server and with port 1935 open to the outside should see that this is true of their setup as well.  I'm wondering if I can safely close port 1935 without limiting the functionality of the server or if there's some way I can require authentication prior to publishing a live stream even though I'm not on the four-and-a-half-times-more-expensive edition of the product.

[SE_0208]

FMLE authentication add-in is not supposed to address entire set of publisher - its implemented to work with FMLE. But that does not stop you from writing your own authentication add-in customized to your own needs - you can build your own access plug-in to take care of other publishers or whatever logic you want to have in order to allow or disallow publishers. FMLE authentication add-in is just one example of access plug-in. With current upgrade of FMS 3.5.4 onwards you can write your own access plug-in - so according to me that hole which are talking about can be addressed.

[teh_chicken]

It's a hole.

People will be implementing this add-in because they want clients to be required to authenticate before they publish a stream, and there is a very easy way to bypass this requirement.  I don't really understand why anyone would find this acceptable.  Imagine if somebody wrote a webserver that implemented basic authentication in such a manner as to only require users of Internet Explorer to authenticate, while Firefox users could sail right through; it's their right to be lazy and make it work that way, but it's still stupid, and a hole in their security mechanism.

But then again, as you say, the add-in is what it is, and was written to do just what it does.  Now I can experience the joy of writing my own auth module, to make up for the shortcomings of this software.

Thanks for your reply.

[rubens_queiroz]

I couldn't agree more with you and it really is a mystery to me why such

sloppy design was made in such a fine product. And it's not a hole, it's a

crater.

Rubens

[SE_0208]

FMS Authentication Add-In is solution built by FMLE team to authenticate FMLE Publishers and it was intended to do that and I suppose it does that very well. Its something they did for their publisher solution to work with FMS and though it would be nice but we cannot expect them to build solution which would cater other publishers.

Now with so many publishers being present its not that trivial to design single module which would suffice for whole set of publishers.And according to me blocking all publishers right away and just allowing FMLE using this plug-in might not be best solution. So it is best left to the onus of one who is building solution to customise things according to his own needs.

If Adobe had to improve its solution:Would you prefer a solution which would block all publishers and send response back to them asking for credentials and probably leave it to publisher end how it deals with response?? ( but again each one can just do such implementation on its own )

[teh_chicken]

Now with so many publishers being present its not that trivial to design single module which would suffice for whole set of publishers.And according to me blocking all publishers right away and just allowing FMLE using this plug-in might not be best solution. So it is best left to the onus of one who is building solution to customise things according to his own needs.

Bear in mind that not everybody is using FMIS.  Users of FMSS didn't buy this product with the expectation of having to build applications and develop plug-ins (in fact, in the case of the former they explicitly cannot do so) - they bought it so that they could have a streaming server.  As far as users of FMSS are concerned, I would think, the solution has already been built - by Adobe - and it's been found to be lacking a very basic element.

As it stands, even the authentication add-in that was developed for use with FMLE clients provides no security whatsoever.  It would need to be modified in such a way as to permit access only to FMLE and block other client software before it served any useful purpose.

So yes, what I think would be useful would be a change at the protocol level / on the server side.  An option to prompt all clients for credentials and allow or deny them access based on their response would be useful.  Otherwise server admins will have to know about each and every piece of client software that may wish to publish a stream to their server and then . . . what - make modifications to their authentication module every time a new client pops up?  Yes, a central, standard authentication system (like what is employed in pretty much every other client-server system that makes provisions for the requirement of authentication) makes a lot of sense.

[Asa_-_FMS]

Acknowledged on the unideal nature of the solution here.

However there's a certain and defined way to handle this problem and that's the combination of SWFV and the FMLE authentication add in.  It's available to all flavors of FMS now (remedied that from earlier) and creates an effective 1, 2 punch.  I talk a little about that and other security elements here

http://www.adobe.com/devnet/flashmediaserver/articles/hardening_guide.html

So, there is a way to secure this that we've documented.  Again, I can appreciate that's not very appetizing for some and  appreciate the feedback that you're looking for a one switch solution  for this.  Message received there.

Asa