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.
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:
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.
There are several methods of user authentication available with Flash Media Server 3.
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):
- 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.so) could authorize the client connection;
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
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.
Flash Media Server 3 offers two options for encrypting your streams.
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).
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:
- Enhanced RTMP:
- Tunneled Enhanced RTMP:
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.
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: