Red5 Authentication

May 7th, 2012 by Paul Gregoire

How to implement CRAM authentication in Red5

In this post we will setup a challenge-response authentication mechanism (CRAM) in a Red5 application using two different methods; the first one being very simple and the other utilizing the powerful Spring security libraries. A basic challenge-response process works like so:

  • Client requests a session
  • Server generates a unique, random ChallengeString (e.g. salt, guid) as well as a SessionID and sends both to client
  • Client gets UserID and Password from UI. Hashes the password once and call it PasswordHash. Then combines PasswordHash with the random string received from server in step 2, and hashes them together again, call this ResponseString
  • Client sends the server UserID, ResponseString and SessionID
  • Server looks up users stored PasswordHash based on UserID, and the original ChallengeString based on SessionID. Then computes the ResponseHash by hashing the PasswordHash and ChallengeString. If its equal to the ResponseString sent by user, then authentication succeeds.

Before we proceed further, it is assumed that you are somewhat familiar with Red5 applications and the Flex SDK. For those who would like a quick set of screencasts to get up-to-speed, we offer the following:


Implementing a security mechanism is as simple as adding an application lifecycle listener to your application. Red5 supports a couple types of CRAM authentication via an available auth plugin. The first one implements the FMS authentication routine and the other one is a custom routine developed by the Red5 team. In this post we will use the Red5 routine. An ApplicationLifecycle class implementing the Red5 routine, may be found in the Red5 source repository; this code only validates against the password “test”. While this class would not be useful in production, it may certainly be used as a starting point for a real implementation. Red5AuthenticationHandler Source

To enable the usage of your Red5AuthenticationHandler class or any other ApplicationLifecycle type class for that matter, you must add it to the listeners in your Application’s appStart method.

The reason for putting it in the appStart method is to ensure that the handler is added when your application starts and before it starts accepting connections. There is no other code to add to your application adapter at this point since the lifecycle methods will fire in your handler. Putting the authentication code within a lifecycle handler serves to keep the adapter code cleaner and less confusing. The authentication handler is defined in the red5-web.xml like so:

At this point, your application would require authentication before a connection would be allowed to proceed beyond “connect”. Entering any user name and the password of “test” or “password” (depends on class used in demo) would allow a client to be connected. As stated previously, this first “simple” implementation is not meant for production but is offered as a means to understand the mechanism at work.

Adding Spring Security

Once we add security layers such as Spring security, the application and authentication features become much more robust. The first thing we must do is to add the Spring Security namespace to our applications red5-web.xml.

Replace this node:

With this node:

Add the authentication manager bean and configure it to use a plain text file. The users file contains our users, passwords, and their credentials.

To demonstrate how users are handled, we will create three users: 1 admin, 1 regular user, and 1 user without a role. The plain text users file follows this pattern: username=password,grantedAuthority[,grantedAuthority][,enabled|disabled] A user can have more than one role specified; granted authority and role are synonymous. Below are the contents of our users file for this demo.

In addition to the authentication handler, a authentication manager must be added when using Spring security. The manager should be added to the appStart method prior to adding the handler, as shown below.

The Spring security version of the authentication handler will replace the simple version in your red5-web.xml like so:

Lastly, an aggregated user details service is used for storage and look ups of user details; this is essentially an interface to the internal in-memory datastore holding the user details or credentials. The user details may be configured to retrieve details from our local properties file, databases, ldap, or active directory. Our aggregated service is fairly simple as you can see below.

It should be noted that Spring security makes use of an additional Spring framework library that is not included in Red5; the transaction library provides DAO and transaction implementations which do not require an external database or related dependencies. All the libraries required for the demo are included in the project zip file.

Client code

Creation of an authentication enabled client will require a single library not included in Flex / Flash builder called as3crypto. The AS3 cryptography library will provide the hashing functions nessasary for authentication in our demo. Download the as3crypto.swc from: and place it in the “libs” folder of our client project.

The following functions will be needed in your client support authentication:

The sendCreds method is called “later” from the sendCredentials method to prevent issues in the event thread.

These are the imports that need to be added before beginning.

In your connect function you will need to determine which authentication mode to employ. The following block will show how to set up the connect call based on the type selected.

You may notice that the type is simply a string in the url denoting which mode to use.

In your net status event handler, you will need to add handling for authentication routines. The following block demonstrates how to do so when an NetConnection.Connect.Rejected is received.

Once you are successfully connected, there are two methods in the demo code for testing access. The helloAdmin method will return a positive result if the authenticated user has the admin permission. In the helloUser method the routine is similar, but only the user permission is required. The included users file contains an admin user and two regular users, the second user is set up to have no permissions. The user without permissions may only connect application and call unprotected methods.

Protected methods in the application contain an isAuthorized check against preselected permissions.

If the user does not qualify, the call fails.

In a future post, I will explain how to add Java Authentication and Authorization Service (JAAS) to Red5.

Project Source Client and server

, , , , , , , , , ,