Jon Rose is an enterprise software consultant and Flex Practice Director at Gorilla Logic, Inc. ( located in Boulder, Colorado. He is an editor and contributor to, an enterprise software community. He is the co-host of, a videocast for those who like booze and bits. He has worked with clients large and small in both the private sector and government. His love of solving problems drives him to build quality software. You can read his blog at: Jon has posted 3 posts at DZone. View Full User Profile

Enterprise Security for Flex

  • submit to reddit

The Spring BlazeDS Integration project combined with the new Flexible Chimp project for client-side filtering provides an ideal solution for fully securing enterprise Flex applications.

Though it is one of the most important aspects of enterprise applications, security can also be among the most difficult aspects of software development. For this reason, security should be considered early in the development of an application. When defining the security of an application, the AAA (authentication, authorization, and access control) paradigm is commonly used to categorize how each aspect of the application should be secured. Some security controls are purposely redundant to provide two layers of security.

When securing Flex applications, there are a variety of resources that need to be secured, including what data a user is able to see, what modules they can load, or what screens they can access. At a finer-grained level of security, you may need to limit a user to reading (but not writing) certain data or hide certain components in the user interface. In addition to providing integration between BlazeDS and a Java back end implemented with Spring, the Spring BlazeDS Integration project offers features to secure the Java services used by your Flex applications, providing an integrated solution with Spring Security. This solution enables you to define security at a service and method level of endpoints defined in BlazeDS and on Spring Beans.

Flexible Chimp is a new project, by Gorilla Logic, that provides permission-based filtering for Adobe Flex and AIR applications. Individual components can be secured based on the roles of a user. Chimp provides client-side security of the user interface through permission-based filtering of components. Applications implement Chimp by adding metadata within instances of the Flex UIComponent class. Based on the metadata, Chimp will remove components completely, enable them, disable them, or update their visibility. For more information, see the Flexible Chimp project website.

Note: This tutorial was co-authored with Ryan Knight, a Senior Software Architect at Gorilla Logic.



In order to make the most of this article, you need the following software and files:

Flex Builder 3


Sample files:
Prerequisite knowledge

Familiarity with BlazeDS and Spring, as well as some knowledge of the Spring BlazeDS Integration project will be helpful.

Reviewing the three As of security

Enterprise developers should be familiar with the three As of security:

  • Authentication, or verifying the identity of a person, is usually done with a username and password on the Internet. It can also be done by retrieving the credentials from a single sign on (SSO) or other external system that is trusted.
  • Authorization is the process of determining what resources a person can access. This is most often done by defining the various roles in a system and then assigning the roles to different users and groups. This process is similar to checking tickets at a ski resort or seeing if a person is on the guest list of an exclusive party.
  • Access control refers to how the various resources of system are protected. It defines who is allowed to access which resources and the conditions for accessing the resources. It is analogous to seating in a plane, in which exit row seats are assigned only to those over a certain age and first class is reserved to those with special tickets.

Securing the server

This section provides a basic overview of configuring your Java server with the Spring BlazeDS Integration project. For an in depth reference, see the Spring BlazeDS Integration project page or DZone's Refcard.

Configuring server-side security in Spring

To secure communications with the server, the Spring BlazeDS Integration project uses an authentication and authorization process based on Spring Security. This process integrates Spring Security with the BlazeDS security process.

To configure the server side of the project, you'll need to edit your web.xml file. In this file, add an additional context configuration file for defining the Spring Security context:

 <!-- The front controller of this Spring Web application, responsible for handling all application requests -->

Also, in web.xml, take note of the URL mapping to be sure it matches the channel definitions defined for BlazeDS. In this sample, map to the MessageBroker URL:

   <!-- Map all *.spring requests to the DispatcherServlet for handling -->


In the Flex configuration file, services.xml, make sure the URL definition also maps to the MessageBroker URL:

       <channel-definition id="my-amf" class="mx.messaging.channels.AMFChannel">
<endpoint url="http://{}:{server.port}/{context.root}/gorilla/messagebroker/amf"

<channel-definition id="my-secure-amf" class="mx.messaging.channels.SecureAMFChannel">
<endpoint url="https://{}:{server.port}/{context.root}/gorillamessagebroker/amfsecure"

Now that the channels are defined and the dispatch servlet is set up, you can define the security context, which was referred to in the web.xml file. The security-context.xml file defines the users and roles for the application. Here is an example configuration for an authentication provider:

<user name="ryan" password="utah" authorities="ROLE_USER, ROLE_ADMIN" />
<user name="jon" password="colorado" authorities="ROLE_USER" />
Securing access to remote services

Remote services are declared as Spring Beans in the application context file, web-application-config.xml. The sample file defines the same class as two separate beans for example purposes. The first one is the sodaService and the second is securedSodaService. The second secures the remote service by defining what roles can access the service:

    <!-- A secured version of productService -->
<bean id="securedSodaService" class="com.gorillalogic.sodaBank.SodaService" >
<flex:remoting-destination />
<security:protect method="get*" access="ROLE_USER" />

Security with Spring and BlazeDS can be as simple or as complex as your requirements dictate. You can secure entire Spring beans by role, or apply more fined-grained access control by defining which methods are exposed and who can access the methods.

With the new Spring BlazeDS Integration project, combining Spring and BlazeDS is easy and straightforward, making it easy to add security to your services with Spring Security.

Now that you have reviewed the Spring and BlazeDS integration, it is time to build on server-side security by protecting the client with the Flexible Chimp project.

Published at DZone with permission of its author, Jon Rose. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Erdos Sam replied on Mon, 2010/03/29 - 11:36pm

Nice article, thanks. But, how to enable/disable the item renderer according to the role?
For example i want to enabled/disabled the itemrenderer bellow

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.