The security problem

Put simply, a secure application must first know who you are and then what you are allowed to do. Applications use authentication to ensure you are who you say you are and authorization to determine if you are allowed to do what you are trying to do. For web applications, authentication is a territory that is well known. There are many authentication methods, including username/password, iris scan, finger print, and tokens.

Authentication works the same in rich clients, including those built with Flex. If, however, you are creating applications that will function offline as well (for example Adobe AIR applications), there are some limitations to consider. The sample application, for instance, uses a username/password combination that is checked on the server. Therefore you cannot use the application without a network connection. Also, note that because it is a basic example, it does not use HTTPS or other forms of encryption that would normally be implemented for a secure application.

High level architecture of the solution

The sample application consists of two main parts, the client and the server. The architecture for the client is straightforward. It is a Flex component, deployed as a SWF file. The server component is more complex (see Figure 1).

Figure 1. High level overview of the architecture of a common web application. Green boxes are Spring framework modules, red are Adobe modules and the blue are custom made.

In the server part of Figure 1, the green boxes are Spring framework modules, the red are Adobe modules, and the blue are custom, although they contain Spring functionality as well. The classes are wired using a Spring application context, transactions are configured over the service methods, method level security is configured, and so on. Because this is an article about the Flex integration, I will not elaborate on the Spring specifics. I will, however, explain the security configuration. As you can see from Figure 1, there are two places where Spring security is used. The first is intercepting web calls by filtering the URLs. The second is securing method calls. Because I expose the Spring beans using BlazeDS directly to the Flex client, this method level security is very important.

The sample

The sample application shows a list of books that you can filter and sort. To illustrate the use of different roles, only administrators (admins) can add new books. The sample uses Maven to build the WAR file and the Flex SWF file. For more information on how that works, see Sébastien Arbogast’s article at http://www.adobe.com/devnet/flex/articles/fullstack_pt3.html. Figure 2 shows an overview of the different components of the application.

Figure 2 Component diagram of the sample application. The yellow components are JAR files, the blue is a WAR file, the red is a Flex SWF file and the grey is only for configuration purposes. The WAR file is the deployable unit that will contain all other components.

Page 2 of 5

Previous Page

Next Page