-Requirements
 
User level
All
Adobe Flash Media Server 3 (FMS 3) is a scalable, real-time media server that delivers high-quality (up to HD) on-demand and live audio and video with great efficiency, and with superior quality of service. FMS 3 allows you to reach the largest possible audience, regardless of platform. It can deliver prerecorded video, live video, playlists, music, video blogging, video messaging, multimedia chat environments, real-time datacasting, multi-user gaming, and more.
With real-time data, video, and audio content, these kinds of applications have the potential to push a heavy data load. Naturally, media servers have only a finite capacity, so as traffic and throughput increase, streaming media applications need to be scaled to preserve the quality of service to your audience. Below are some of the ways you can address this situation:
  • Cluster deployment: You can deploy multiple servers behind a load balancer to distribute application load evenly. Flash Media Server (FMS) clustering enables you to scale an application to accommodate more clients reliably, and creates redundancy, which eliminates single points of failure. This approach is generally best for live or video-on-demand (VOD) streaming, where clients do not need to communicate with one another from within specific application instances. Clustering can be achieved using either Flash Media Streaming Server (FMSS) or Flash Media Interactive Server (FMIS).
  • FMS intelligent balancing: With Flash Media Interactive Server, you can intelligently direct traffic to a multiple server cluster using server-side scripting. This option would typically be used for multi-way communication applications that require connections to be routed to a specific server. This option does require development of rather sophisticated server-side ActionScript to manage connections.
  • Edge/origin configurations: In the past, Flash Media Server–distributed caching/load balancing was achieved by purchasing the Edge/Origin editions. This functionality is now built into Flash Media Interactive Server. FMIS provides an enterprise-ready architecture designed to simplify load balancing, failover, and clustering to ensure maximum availability over large regions.
This article discusses the flexible options that Flash Media Server offers for gracefully scaling high-traffic applications. I also discuss the security features that Flash Media Server offers to protect your content and server resources in ways that are unobtrusive, intuitive, and convenient to consumers.

Scaling edge/origin deployments

Edge/origin server configurations improve performance by distributing the server load among many computers on a network (see Figure 1). With an edge/origin deployment strategy, all connection requests from clients are redirected to an edge server. The configuration also lets you maximize your network if you are supporting a large local network. By placing edge servers in remote office locations, the edge servers will cache media files locally so each stream does not need to access the origin (host) server for each stream.
Figure 1
Figure 1. Edge/origin architecture
Typically edge/origin deployments are best used with one-way streaming services. When using custom server-side applications to enable real-time communication, the edge server strictly handles the requests on behalf of the origin server. Client connections then make round trips to the origin server to run the application.
 
In FMIS, edge-level support for bandwidth detection and stream length detection has been integrated. The first server in the chain (edge or origin) receiving a stream call will also handle the bandwidth check and stream length check without calling the origin server script layer. This feature is compatible with the FLVPlayback component for Flash 8 or Flash CS3.
 
When a client request is received, the edge server will handle the tasks it can, and then make a connection to the origin server for any additional data required. When the origin server fulfills the request, the data is sent back to the edge server, and then on to the client. To the client, it appears that the connection is made directly to the application running on the origin server.
 
The edge server serves as a "traffic cop" handling connection overhead, authentication, and other administrative duties, freeing up valuable system and network resources for the origin server. Every connection, and connection attempt, consumes resources over and above the actual stream data flowing through the connection. As the number and frequency of connections increase, the load can be excessive, adversely affecting server performance. The edge server greatly reduces this load by aggregating connections. The edge multiplexes the connections from a large number of clients into one connection to the origin server. All communications between edge and origin servers are transparent to clients.
 
The edge server also stores the prerecorded media content received from the origin server in a cache, which is then made available to other clients that connect to the edge server. Caching static content further reduces the load on the origin server.
 
Deployment strategies
 
The simple way to distribute load among edge servers is to assign users in a geographical region or other delineation to a specific edge server. For example, one edge server may aggregate and forward requests from clients in London, while another may handle requests from Tokyo.
 
A typical networked Flash Media Server deployment can involve multiple edge servers, deployed either individually or in clusters. Edge servers can also be chained, allowing even further distribution of traffic.
To enable the edge/origin feature, you can configure any server in your cluster as your origin server(s), and the rest as your edge servers. All editions in an edge/origin configuration must be the same (for example, you cannot mix FMSS and FMIS editions in a cluster).
 
Large-scale FMS deployments are supported with the FMS edge/origin configuration. For an introduction to FMS edge/origin, please refer to the documentation, Using Flash Media Server edge servers. For instructions for setting up an edge server, refer to "Configuring edge servers" (p. 5) in the Flash Media Server Configuration and Administration Guide.
 
Edge servers are also referred to as proxy servers. There are four ways to configure an FMS edge (or proxy) server:
  • Client auto discovery proxy
  • Server auto discover (reverse proxy)
  • Explicit URI
  • Implicit URI (recommended)
Typically, the last configuration (implicit URI) is the recommended setting because it is the most secure and requires the least amount of communication. It can hide the origin server URI and is the easiest to set up.
 
All of these methods are described in the documentation, Using Flash Media Server edge servers. This article explores implicit URI configuration.
 
Configuring proxy (edge) servers using implicit URI
 
In typical large-scale deployments, your business could deploy the implicit URI method.
The following settings define the virtual host as a proxy (edge) server:
<Proxy> <Mode>remote</Mode> <Anonymous>false</Anonymous> <CacheDir enabled="true" useAppName="true">d:\fmsCache\</CacheDir> <LocalAddress></LocalAddress> <RouteTable protocol=""> <RouteEntry>edge1.fms.com:*;192.168.110.150:1935</RouteEntry> </RouteTable> </Proxy>
This configuration will allow the client to connect with the edge server without exposing the proxy server.
The connection string would look like this:
rtmp://edge1.fms.com/ondemand/

Flash Player would connect to the edge server and not expose the origin server at 192.168.110.50 (see Figure 2).

Figure 2
Figure 2. Edge server using a single origin server
You can configure edge servers to create proxy clusters. In Figure 3 notice how an edge server (e1) can proxy the edge server (e0) in its RouteEntry tag. e0 would proxy the FMS origin. This type of configuration will allow you build FMS edge clusters that could be geographically balanced.
Figure 3
Figure 3. Edge server cluster using a master edge and a single origin
The RouteEntry for the cluster members would point to a main edge server:
<RouteTable protocol=""> <RouteEntry>edge1.fms.com:*;edge0.fms.com:*;</RouteEntry> </RouteTable>
The RouteEntry for the main proxy (edge server) in the cluster would point back to the origin server:
<RouteTable protocol=""> <RouteEntry>edge0.fms.com:*;origin.fms.com:*;</RouteEntry> </RouteTable>

Securing streaming content

Whenever content is distributed electronically, there is some risk of it being copied, misappropriated, or redistributed. Flash Media Server offers several levels of security to protect your content and server resources that are unobtrusive, intuitive, and convenient to consumers.
 
Content vulnerabilities
There are a number of ways that online digital content can be compromised:
  • Raiding the browser cache: Though the filenames are not easily read, it is relatively simple to retrieve video files from the browser cache. (This vulnerability is only present with progressive video delivery; streams are never cached.)
  • Video URI access: Video URIs can easily be discovered using free "sniffer" utilities.
  • SWF re-serving: Your SWF can be copied and re-served from another domain. SWFs can also be decompiled, often revealing your FMS address, application and stream names.
  • Replay technologies: Also referred to as "stream ripping," this is the most insidious of security issues as it is more difficult to prevent. Stream ripping utilities actually intercept the data stream and record it to a file that can then be played.
FMS security architecture
As discussed earlier, streaming inherently has a higher level of security than progressive delivery, since media files are never cached to disk. Flash Media Server further enhances protection against other risks with a number of additional security features:
  • User authentication using server-side ActionScript
  • Authorization adaptor
  • Access adaptor
  • SWF verification
  • Domain access control
  • Custom solutions offered by content delivery networks
  • Stream encryption using RTMPE or RTMPS
Let's first look at the overall security model of FMS (see Figure 4) and then examine each of the protection measures more in depth.
Figure 4
Figure 4. Flash media server security architecture

Locking down your content

Regardless of the sensitivity or ownership of your content, you'll want to implement some level of security when deploying to the web. It is best to begin by securing your server and then securing your content. Let's examine each of the security measures you can take in more detail.
 
Restrict access from domains
 
By default, a client can connect to Flash Media Server from any domain or IP address, which can be a security risk. You can create a whitelist of allowed domains (or a blacklist of banned domains) to ensure that only authorized clients can connect to your applications or services. You can add a comma-delimited list of domains and/or IP-address blocks in the Adaptor.xml or vHost.xml configuration files to add this level of security. This is usually the first step in locking down your server, and it prevents malicious or unauthorized domains from freely accessing your applications and streams.
 
User authentication
There are several methods of user authentication available with Flash Media Server 3.
 
Server-side ActionScript
The next step to increase security would be to implement a user authentication scheme to validate the connecting client. For example, using variables passed in through the client NetConnection method, you could implement a simple username/password, an encrypted token (MD5 Hash), or a unique key:
  • User credentials (login/password):
    NetConnection.connect("rtmp://yourFMSserver.com", "username", "password");
  • Encrypted token (MD5 Hash):
    NetConnection.connect("rtmp://yourFMSserver.com", 6aef79f07bc8f23c38e8979f3630f436);
  • Unique key:
    NetConnection.connect("rtmp://yourFMSserver.com ", 349jh3k4324h9.234234098);
Then, on the server side, FMS would be able to integrate with web services (SOAP), Flash Remoting, XML, HTTP Post (loadVars) or simple file access to validate the client based on the data sent. This authentication scheme could be as simple as checking login information against a database, or as complex as creating an SSL-based token system using ColdFusion.
 
Access adaptor plug-in
 

Note: This is an update feature, FMIS only, Flash Player 6 minimum.

An Access adaptor is a server plug-in written in C++ that intercepts connections to the server, and determines whether requests should be accepted, rejected, or redirected before the requests reach the server's script layer. You can create custom logic in the Access adaptor to handle client connection requests. For example, you could query your account database upon client login, and then update the database record after the client connection was accepted.
 
The Access adaptor can be configured to accept or reject requests based on the number of clients currently connected or the amount of bandwidth currently being consumed. You can also set read and write access for files and folders on the server, set permissions to access audio and video bitmap data, and inspect client properties through the Access adaptor.
 
When you use the Access adaptor, you are actually catching the connection before it is processed by FMS. For this reason, you are limited to trapping only the connection events. If you want to apply additional rules after the connection is established, you would then configure an Authorization adaptor.
 

Note: There can only be one Access plug-in per Flash Media Interactive Server installation.

Authorization adaptor plug-in
 

Note: This is a new feature, FMIS only, Flash Player 6 minimum.

The next line of defense is the Authorization adaptor. A server plug-in written in C++, the Authorization adaptor authorizes client access to server events. Once the connection has been established, but before it is accepted, the Authorization adaptor comes into play.
 
Authorization adaptors can do the following:
  • Authorize connections to the server
  • Authorize playing a stream or seeking in a stream
  • Authorize publishing a stream
  • Disconnect clients from the server
  • Call a method in server-side ActionScript
  • Deliver content to clients according to their geographic location, subscription level, or stream origin
  • Limit time and duration of a user's access to specific streams
  • Map logical stream path to physical stream path (for example, a client requests the stream "foo.flv," but since he is not a premium member of the service, he should only receive the low-quality version of that content, so he is actually served "bar.flv")
Unlike the Access adaptor, you can use multiple Authorization adaptors to sequentially perform actions on the incoming event. For example, auth1.dll (or auth1.so) could authorize the client connection; auth2.dll (or auth2.so) could then authorize that client to publish a stream, and so on. The server applies the adaptors in alphabetical order.
 
As you can see, Authorization adaptors can be very powerful for stream security and access control at a granular level. They can be configured to implement custom functionality ranging from rights management to logging.
 
Dynamic access control
 
When clients access the server, they have full access to all streams and shared objects by default. Access control is possible, however, using server-side ActionScript. You can create a dynamic access control list (ACL) which controls who has access to read, create, or update shared objects or streams.
 
In server-side ActionScript, each client that connects is assigned to a Client object. Each Client object has readAccess and writeAccess properties. These properties can accept multiple comma-delimited values. By setting these values when you accept the client connection, you can control which streams and shared objects any given client can access.
 
Stream encryption
Flash Media Server 3 offers two options for encrypting your streams.
 
SSL
 

Note: This is an existing feature for FMSS/FMIS, Flash Player 8 minimum.

In earlier versions of FMS, encrypted streaming was available using secure socket layer (SSL) delivery through the RTMPS protocol. This form of encryption is still supported in FMS 3. Implementation requires the use of a third-party certificate, however, requiring some server-side configuration. FMS 3 now offers an optimized and easier-to-implement encryption solution, the encrypted RTMP protocol (RTMPE).
 
RTMPE
 

Note: This is a new feature for FMSS/FMIS, Flash Player 9,0,115,0 required.

Encrypted RTMP (RTMPE) is enabled on FMS by default, and allows you to send streams over an encrypted connection without requiring certificate management. Offering secure 128-bit encryption, RTMPE is supported only in Flash Player 9 and later, with the updated FLVPlayback component and NetConnection classes. Both SSL and RTMPE can also be "tunneled" to ensure connectivity through network firewalls. RTMPE is the recommended form of encryption, as it is easier to deploy and is much faster than SSL.

Implementing stream encryption in your applications is easy. Simply specify the protocol when you connect to your application:

  • SSL:
    NetConnection.connect("rtmps://yourFMSserver.com");
  • Enhanced RTMP:
    NetConnection.connect("rtmpe://yourFMSserver.com");
  • Tunneled Enhanced RTMP:
    NetConnection.connect("rtmpte://yourFMSserver.com");
Defend against replay technologies
 
Replay technologies, or "stream ripping," has been a difficult security issue to solve because it allows the viewer to directly access and record the data of a stream.
Stream encryption prevents stream ripping. In the past, SSL was the only choice and was too slow for most applications. With FMS 3, we now have the RTMPE protocol which is much more efficient and easier to implement.
 
Another method of defense against stream ripping is to insert intelligence into your server-client communications. By adding some code to your video player, you could require your SWF to respond to a request from FMS to verify a unique string sent from the server, for example. This interrupts the flow of data to the stream ripping software, as it cannot respond with the correct data and will be denied access.
 
DRM support
 

Note: This is a new feature for FMSS/FMIS, Flash Player 6 minimum, except RTMPE/SWF verification – Flash Player 9,0,115,0 is the minimum.

Digital rights management (DRM) has two key elements, encryption and access control. There are two ways to deliver video to a consumer: stream it or download it. When you stream video from Flash Media Server, you immediately increase your protection.
 
Encryption with Flash Media Server is done in real time with RTMPS (SSL) or RTMPE in Flash Media Server 3.
 
Access control with Flash Media Server is done simply with SWF verification. Access control is much more powerful with Flash Media Interactive Server because of its new plug-in architecture, along with the server-side application layer. Using web services (SOAP), Flash Remoting, or XML you can create a system with secure tokens that provide access control over your content.
 
These are the basic principles of DRM for streaming. For the download use case, Adobe will be releasing new technology with Adobe Media Player in 2008.
 
Where to go from here
 
An easy way to add content protection to your streaming content is to use Flash Video Streaming Services (FVSS) through Adobe's content delivery network (CDN) partners. Many of Adobe's FVSS partners offer plug-and-play restricted access and secure video streaming solutions.
 
To learn more about how a Content Delivery Network can help protect your content, visit the Flash Video Streaming Service area on the Adobe website.
 
You can also read the notes from a presentation that Will Law and Stefan Richter gave at MAX 2007 about FMS security: