Neosavvy, Inc Modern Knowledge Blog

Building a Simple Login Mechanism in Flex – Part 2 (Enabling Spring Security)

This guide is an extension to the previous post http://blog.neosavvy.com/wordpress/?p=18 that described how to build a simple Flex project with Maven and also create the necessary base to start securing simple features in an application with BlazeDS integrations provided by Spring-Flex.

Please note that all SVN Links are temporarily locked down - I apologize for the inconvenience but please find the source here: http://www.neosavvy.com/commons-user-blog-post.tar.gz

In this article we will address the following topics:

1. Adding spring-security 2.0.5 as a dependency
2. Adding spring-flex 1.0.1.RELEASE as a dependency
3. Defining security with annotations on UserService with one role
4. Making Login calls from Flex to secured services
5. Making Logout calls from Flex to secured services
6. Accessing user and authority information after a successful login call

Adding spring-security 2.0.5 and spring-flex 1.0.1.RELEASE is simple if your application uses Maven

Add the following dependencies to your top level pom.xml and also add them without versions to your WAR and JAR pom.xml files.

           <dependency>
                <groupId>org.springframework</groupId>
                <artifactId>spring-webmvc</artifactId>
                <version>${spring.version}</version>
                <exclusions>
                    <exclusion>
                        <artifactId>com.springsource.javax.validation</artifactId>
                        <groupId>javax.validation</groupId>
                    </exclusion>
                </exclusions>
            </dependency>
            <dependency>
                <groupId>org.springframework.flex</groupId>
                <artifactId>spring-flex</artifactId>
                <version>1.0.1.RELEASE</version>
            </dependency>
            <dependency>
                <groupId>org.springframework.security</groupId>
                <artifactId>spring-security-core</artifactId>
                <version>${spring.security.version}</version>
            </dependency>
            <dependency>
                <groupId>org.springframework.security</groupId>
                <artifactId>spring-security-core-tiger</artifactId>
                <version>${spring.security.version}</version>
            </dependency>

Spring-webmvc is used for its DispatcherServlet in the servlet.xml file and the javax.validation artifacts caused a ClassLoader issue when starting the WAR so it is excluded as a transitive dependency. The latest release of spring-flex is 1.0.1.RELEASE and is included as that version. The base spring-security classes are part of spring-security-core and the Java 1.5 compliant classes are part of spring-security-core-tiger. Without that library the @Secured() annotations will not work.

After the necessary dependencies are included securing the service is as simple as adding some annotations to the interface of the message broker exposed service that necessitates security.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

package com.neosavvy.user.service;
 
import com.neosavvy.user.dto.UserDTO;
import org.springframework.security.annotation.Secured;
 
import java.util.List;
 
public interface UserService {
 
    @Secured("ROLE_ADMIN")
    public List<UserDTO> getUsers();
 
    public void saveUser(UserDTO user);
 
    @Secured("ROLE_ADMIN")
    public UserDTO findUserById(int id);
 
    @Secured("ROLE_ADMIN")
    public List<UserDTO> findUsers(UserDTO user);
 
    @Secured("ROLE_ADMIN")
    public void deleteUser(UserDTO user);
 
    public Boolean login(UserDTO user);
 
    public Boolean logout(UserDTO user);
 
}

Notice in the above class that all @Secured annotations at this time have a value of “ROLE_ADMIN” which means that the “ROLE_ADMIN” privilege is required when a user is looked up from the security DAO. More on this later.

The WAR configuration needs some modification to expose the services as secured services. This requires the use of DispatcherServlet instead of ContextLoaderListener to initialize spring in the web.xml.

<!DOCTYPE web-app PUBLIC
        "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
        "http://java.sun.com/dtd/web-app_2_3.dtd" >
 
<web-app>
 
    <display-name>COMMONS-USER-SERVICE</display-name>
 
    <listener>
        <listener-class>flex.messaging.HttpFlexSession</listener-class>
    </listener>
 
    <servlet>
        <servlet-name>Spring MVC Dispatcher Servlet</servlet-name>
        <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
        <init-param>
            <param-name>contextConfigLocation</param-name>
            <param-value>
                classpath*:applicationContext.xml
                classpath:flexContext.xml
                classpath:securityContext.xml
            </param-value>
        </init-param>
        <load-on-startup>1</load-on-startup>
    </servlet>
 
    <servlet-mapping>
        <servlet-name>Spring MVC Dispatcher Servlet</servlet-name>
        <url-pattern>/messagebroker/*</url-pattern>
    </servlet-mapping>
 
 
</web-app>

Note that the additional securityContext.xml that is included. This file is used to configure Spring to use spring security. The flexContext.xml also needed a one line adjustment to enable security in the message broker servlet configuration.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:flex="http://www.springframework.org/schema/flex"
       xsi:schemaLocation="
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
http://www.springframework.org/schema/flex http://www.springframework.org/schema/flex/spring-flex-1.0.xsd">
 
    <flex:message-broker>
        <flex:remoting-service default-channels="user-amf"/>
        <flex:secured/>
    </flex:message-broker>
 
    <flex:remoting-destination ref="userService"/>
 
</beans>

Notice the inclusion of that is all that is required to make the annotations on userService respect the ROLE_ADMIN definition. If a user tries to access the method without logging in first, they will receive a security exception at runtime on the client.

Using the following securityContext.xml will enable security and associate the existing UserDTO objects with the login requests when users try to authenticate.

<beans:beans xmlns="http://www.springframework.org/schema/security"
             xmlns:beans="http://www.springframework.org/schema/beans"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://www.springframework.org/schema/beans
                      http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
                      http://www.springframework.org/schema/security
                      http://www.springframework.org/schema/security/spring-security-2.0.4.xsd">
 
    <http entry-point-ref="preAuthenticatedEntryPoint"/>
 
    <beans:bean id="preAuthenticatedEntryPoint"
                class="org.springframework.security.ui.preauth.PreAuthenticatedProcessingFilterEntryPoint"/>
 
    <authentication-provider user-service-ref="authenticationDao"/>
 
    <beans:bean id="authenticationDao" class="org.springframework.security.userdetails.jdbc.JdbcDaoImpl">
        <beans:property name="dataSource" ref="dataSource"/>
        <beans:property name="usersByUsernameQuery">
            <beans:value>
                SELECT USERNAME, PASSWORD, true as enabled FROM USER WHERE USERNAME=?
            </beans:value>
        </beans:property>
        <beans:property name="authoritiesByUsernameQuery">
            <beans:value>
                SELECT USERNAME, 'ROLE_ADMIN' AS PRIVILEGE FROM USER WHERE USERNAME=?
            </beans:value>
        </beans:property>
    </beans:bean>
 
    <global-method-security secured-annotations="enabled" jsr250-annotations="enabled"/>
</beans:beans>

The authoritiesByUsernameQuery is currently a hack that allows all users to have the ROLE_ADMIN but in a later article the differentiation between ROLE_USER and ROLE_ADMIN will be established. The other item of note in this file is that the global-method-security tag enables secured annotations which ensures that the @Secured annotations on the UserService interface are honored.

Flex Cient configuration:

Making a login call is relatively simple and to ensure simplicity the remoteobject is not separated from the view in the example. To perform a login a user will simply type in the username/password and click login. If they do not have a login, they can register a user (saveUser) as that is not restricted by security.

Here is the login functionality in the Login.mxml:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

protected function login():void {
            errorLbl.text = null;
            var userService:RemoteObject = new RemoteObject();
 
            var channel:AMFChannel = new AMFChannel("user-amf", "http://localhost:8080/commons-user-webapp/messagebroker/amf");
            var channelSet:ChannelSet = new ChannelSet();
            channelSet.addChannel(channel);
            userService.channelSet = channelSet;
            userService.destination = "userService";
            channelSet.login(username.text, password.text);
            channelSet.addEventListener(ResultEvent.RESULT, resultHandler);
            channelSet.addEventListener(FaultEvent.FAULT, faultHandler);
        }
 
        protected function resultHandler( result:ResultEvent ):void {
            if (result.result.authorities.indexOf("ROLE_ADMIN") >= 0) {
                trace("User logged in as admin");
            } else {
                trace("User logged in as user");
            }
            FlexGlobals.topLevelApplication.hideRegistrationLoginWindow(result.result);
        }
 
        protected function faultHandler( fault:FaultEvent ):void {
            trace("Login Failed: " + fault.fault.faultString);
            errorLbl.text = "login invalid";
        }

Here is a snippet used in another function to retrieve the user from the object that is returned from the service after a successful call to login:

1
2
3
4
5
6
7
8

     public function hideRegistrationLoginWindow(security:Object):void {
            PopUpManager.removePopUp(regAndLoginWindow);
 
            if(security.hasOwnProperty("name")) {
                usernameLbl.text = security.name;
            }
            initializeService();
        }

Logging out is rather simple as well and requires no parameters. The assumption in this code is that the logout is successful and no error occurs. This may be an unsafe assumption, but for now this will suffice.

    public function logout() {
            var userService:RemoteObject = new RemoteObject();
            var channel:AMFChannel = new AMFChannel("user-amf", "http://localhost:8080/commons-user-webapp/messagebroker/amf");
            var channelSet:ChannelSet = new ChannelSet();
            channelSet.addChannel(channel);
            userService.channelSet = channelSet;
            userService.destination = "userService";
            channelSet.logout();
            showRegistrationLoginWindow();
            usernameLbl.text = "Not Logged In";
        }

Some additional polish was added to this feature in that a getUsers call occurs on initial application startup. Since the user is not logged in yet on initial load of the application a fault occurs and a dialog is displayed to login or register. Additionally the logged in user should display at the top right of the main dialog window.

This is essentially all it takes to secure a flex application in a basic way. Next time the addition of some more ROLE_* information and a better explanation of how the privilege tables works will be included / created. Some new features like enabling and disabling users will also be added. If anyone has a feature request as well posting it on the blog in comments is hugely appreciated and if it seems like a good idea I am happy to try and add it.

Thanks for reading and please contact me at aparrish@neosavvy.com if you have any questions or want to use the code as it is open source and totally free to use in any application for profit or not.

Building a Simple Login Mechanism with Flex, Spring-Flex, and Spring-Security

Introduction

This guide is a step by step architecture walkthrough of a simple Flex application I have constructed to help depict how to build a Flex application with BlazeDS/Java/Hibernate and an in memory database. The attempt will be to use the newest features of Spring to integrate security and BlazeDS integrations since they are relatively new and undocumented at this point.

You can find the code at the time of this writing tagged here: http://www.neosavvy.com/svn/neosavvy/projects/commons-user/tags/initial-integration-of-user-registration-with-blazeds/

Please note that all SVN Links are temporarily locked down - I apologize for the inconvenience but please find the source here: http://www.neosavvy.com/commons-user-blog-post.tar.gz

The following requirements are attempted to be met with this project:

1. Provide a Registration dialog that allows new users to supply Username, Name, Email, and password information
2. Provide a login dialog that allows a user to authenticate
3. Provide a basic user management system that can be used by administrative users and will serve as the user management system for other applications
4. Provide a secured UI and a non-secured UI
   - Non Secured features are Login / Registration screens
   - Secured features are User Management screens (Some admin – some all users)

Now that the rudimentary requirements are out of the way I will explain how the application was specified. I used the application Balsamiq Mockups to design the login and registration screens and they should accurately depict what was attempted to be built.

Simple Design / Wireframes

This first screen that a new user will be prompted to click a button to initialize the user registration process.

Once the new user has clicked the new user button the next screen will be rendered to prompt for necessary input to create a user. This is standard user information and could be extended depending on the scenario needing it.

This screen shows a few simple validation errors that will be integrated to ensure valid user creation.

After a user successfully registers a simple confirmation will be displayed and the users account will be active. For the intent of simplicity no confirmation is required in the code to authorize email addresses or integrate captcha at this time. A similar screen to the one below will be implemented for server side errors when creating a user such as uniqueness constraint violations on user creation.

If you would like to open the BMML files or the PNGs they are checked in here:

http://www.neosavvy.com/svn/neosavvy/projects/commons-user/trunk/doc

They were created with Balsamiq Mockups http://www.balsamiq.com/products/mockups which is a great inexpensive way to create simple mockups of screens before you spend hours trying to make them work.

Architecture

The chosen architecture for this application is going to be my standard architecture for applications produced by Neosavvy for Open Source initiatives. The following technologies are used

1. Maven – Build and Configuration Management
2. Nexus – Dependency management Repository
3. HSQLDB – In Memory RDBMS
4. JUnit 4 – Unit / Integration Testing for Java
5. Java 1.5 (I know it is EOL but this ensures maximum support in the Field at this time as I know of multiple production apps that have not and can not upgrade to 1.6)
6. Tomcat 5.5 for Maven based deployment testing via Cargo Maven plugin
7. Spring 2.5.6 – At the time of writing this is the minimum version to support Spring’s Flex Libraries
8. Spring Flex 1.0.1.RELEASE
9. Hibernate 3.0.GA
10. Flex 4.0.0 – At the time of this writing Flex 4 is in Beta and the Sparc packages are in Flux. The 4.0 version of the Flex SDK is used to build but the MX packages are used for the interface. A conversion to the Sparc packages will occur in a later post to help understand what that entails

The application is organized into separate projects as Maven projects and has the following structure

I have made an attempt to show the dependencies of the projects to depict the build order when maven executes. The top level project is not depicted but the project structure can also be seen by opening the top level pom in IntelliJ.

The intent of each of these project is my standard approach to developing a RIA and is as follows:

Commons-user-java-lib
- All of the Unit / Integration testing lives in this project for Java
- All of the Spring configuration specific to wiring the JAR together lives here
- All of the Value Objects, Service Architecture, and DAOs are defined in this project

Commons-user-flex-model-lib

- This project encapsulates generated DTOs for the frontend consumption
- Autogeneration is accomplished via Flex Mojo’s generator plugin

Commons-user-config

- To configure a BlazeDS application some files are required and can be shared with the flex client and the webapplication configuration
- Extracting them into a separate project allows for the Flex code and Java code to share the configuration rather than duplicate it

Commons-user-webapp

- This project outputs a WAR and assembles the Flex and Java code into a working web application
- Theoretically Java Integration tests more appropriately belong here, but there are some problems making eclipse easily build/test/code/repeat so they were moved to the Jar. IntelliJ handles this fine, but Eclipse is the defacto standard so I moved them.

Commons-user-top-level (not depicted in above diagram)

- This project is the top level project and assembles the modules via multi-module configuration in Maven.
- This also manages dependencies across projects to maintain a uniform set of dependencies
- Properties to share amongst projects are also declared at this level
- Project information related to developers and documentation are also at this level

Java Implementation

Now that the overall architecture is explained let’s explain how the Java implementation was accomplished. I attempted to use a test driven development approach and also leveraged Spring’s test architecture to load Application Context and set database state (by deleting existing values in a transaction).

Test Classes

BaseSpringAwareTestCase ( http://www.neosavvy.com/svn/neosavvy/projects/commons-user/trunk/commons-user-java-lib/src/test/java/com/neosavvy/user/BaseSpringAwareTestCase.java )

This is a good place to start because this class will load your application context for you and allow you to extend it and write good test cases. It’s UML structure is depicted below:

The important part to notice is that it extends from AbstractTransactionalJUnit4SpringContextTests, verything else if for free.

The next class of note is the test suite that verifies all the functionality that is being attempted in this feature.

Click here to see full size diagram

As you can see all of the test cases that support the basic registration functionality and login functionality are stubbed in and at the time of writing have been completely fleshed and and work. (see http://www.neosavvy.com/svn/neosavvy/projects/commons-user/trunk/commons-user-java-lib/src/test/java/com/neosavvy/user/TestUserDAO.java )

Model Classes

The next step usually for me is to define the model classes as can be seen in the diagram below. Source here: http://www.neosavvy.com/svn/neosavvy/projects/commons-user/trunk/commons-user-java-lib/src/main/java/com/neosavvy/user/dto/UserDTO.java

Click here to see full size image

DAO Interface

The next step is to define some basic DAO interface operations. The following were implemented to support the features depicted in the requirements. At this point you will notice none of these will support “login” as this will be a feature of implementing Spring Security later. Source is here: http://www.neosavvy.com/svn/neosavvy/projects/commons-user/trunk/commons-user-java-lib/src/main/java/com/neosavvy/user/dao/UserDAO.java

Click here to see full size diagram

DAO Interface Implementation

Now it is time to write some actual working code. This is done by implementing the DAO interface. Usually it is best to wire the interface’s implementation to your test case before actually coding the functionality. For brevity I will just show the full working class, but you can assume I wrote it that way. It is worth noting that the Implementing class extends HibernateDaoSupport and implements UserDAO. This helps with wiring Spring to datasources and provides transaction support out of the box so you don’t have to think about it.

Click here to see full size image

Spring Configuration

After all this is complete it is time to wire all this together with Spring. This can be done with the applicationContext.xml and some extras are thrown in for JOTM transaction management for deployment to containers like Tomcat that do not have a PlatformTransactionManager. Here is a diagram that depicts the beans that are configured.

Click here to see full size diagram

At this point the Jar definition is complete. The test case runs to completion with no errors and the HSQLDB starts up when Maven executes. The HSQLDB configuration uses an in memory configuration to allow the startup sequence to always have a predictable state.

Configuring the Spring services via BlazeDS / Spring-Flex

Note that this is a great step by step guide to follow: http://static.springsource.org/spring-flex/docs/1.0.x/reference/html/ch01.html

In the commons-user-webapp there is some configuration to Spring that exposes all of the services via BlazeDS.

To start make sure that you are using DispatcherServlet to configure Spring instead of ContextLoaderListener.

Notice the following from the web.xml (http://www.neosavvy.com/svn/neosavvy/projects/commons-user/trunk/commons-user-webapp/src/main/webapp/WEB-INF/web.xml

<servlet>
<servlet-name>Spring MVC Dispatcher Servlet</servlet-name>
<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
<init-param>
<param-name>contextConfigLocation</param-name>
<param-value>
classpath*:applicationContext.xml
classpath:flexContext.xml
</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
 
<servlet-mapping>
<servlet-name>Spring MVC Dispatcher Servlet</servlet-name>
<url-pattern>/messagebroker/*</url-pattern>
</servlet-mapping>

Notice that the flexContext.xml is included without the *. The reason for this is because the * tells Spring to load a resource from any dependent Jar file. The applicationContext.xml lives in commons-user.jar so it has to use the * operator, while the flexContext.xml is in the WEB-INF/classes directory.

About the flexContext.xml file:

All that had to be done to expose the UserService was to point the flexContext.xml at this bean with the following configuration

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:flex="http://www.springframework.org/schema/flex"
xsi:schemaLocation="
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
http://www.springframework.org/schema/flex http://www.springframework.org/schema/flex/spring-flex-1.0.xsd">
 
<flex:message-broker>
<flex:remoting-service default-channels="user-amf" />
</flex:message-broker>
 
<flex:remoting-destination ref="userService" />
 
</beans>

It is also required that you ensure you have the services-config.xml defined in the commons-user-config project. Take a look at the following file: http://www.neosavvy.com/svn/neosavvy/projects/commons-user/trunk/commons-user-config/src/main/resources/services-config.xml

The most important part to ensure that you include is:

<?xml version="1.0" encoding="UTF-8"?>
<services-config>
 
<channels>
<channel-definition id="user-amf" class="mx.messaging.channels.AMFChannel">
<endpoint url="http://{server.name}:{server.port}/{context.root}/messagebroker/amf"
class="flex.messaging.endpoints.AMFEndpoint"/>
<properties>
<polling-enabled>false</polling-enabled>
</properties>
</channel-definition>
</channels>
</services-config>

At this point all that is required to test and ensure that the BlazeDS integration is complete.

Flex Implementation

The next step is to get those model objects proxied on the Flex side as actionscript. I leveraged Marvin Froeder’s Flex Mojo’s plugin that hooks into the GAS3 groovy based actionscript generation tools. This generates all the classes specified in the POM file for maven and places a Base class in the target/generated-classes/flex directory before compiling a SWC. All the extended versions of the classes end up in src/main/flex/com/neosavvy/dto/ and allow a developer to put custom logic there.

Take a look at the following to understand how code generation works:

<build>
<plugins>
<plugin>
<groupId>org.sonatype.flexmojos</groupId>
<artifactId>flexmojos-maven-plugin</artifactId>
<version>${flex.mojos.maven.version}</version>
<executions>
<execution>
<goals>
<goal>generate</goal>
</goals>
<configuration>
<includeJavaClasses>
<includeClass>com.neosavvy.user.dto.*</includeClass>
</includeJavaClasses>
<beanTemplate>
<template>${basedir}/src/main/template/beanBase.gsp</template>
<template>${basedir}/src/main/template/bean.gsp
</template>
</beanTemplate>
</configuration>
</execution>
</executions>
<configuration>
<configurationReport>true</configurationReport>
<debug>true</debug>
<locales>
<param>en_US</param>
</locales>
<targetPlayer>10.0.0</targetPlayer>
</configuration>
</plugin>
</plugins>
</build>

It is also necessary to add a dependency to the Jar project as a provided scope to allow the generator plugin to find the Java classes it is supposed to generate.

<dependency>
<groupId>com.neosavvy.commons.user</groupId>
<artifactId>commons-user-java-lib</artifactId>
<version>1.0-SNAPSHOT</version>
<scope>provided</scope>
</dependency>

Executing the maven build on this project will cause the classes to get regenerated.

Now in the interest of not using complicated frameworks but focusing on the integration points of Flex I have used some not-so-best practices when developing the Flex client. There are frequent examples of RemoteObjects defined in the mx:Script section of some of these components. I plan to use this as a starting point for new Flex developers as it is likely that they would attempt to develop in this way if they are just starting out.

The RegistrationAndLoginWindow.mxml is the top level MXML document that handles transitioning between the error screens and the registration screens. The actual code to implement the service calls is in the UserRegistration.mxml file. The two error handling files are UserFailed.mxml and UserConfirmed.mxml. The NewUserRegistration.mxml is what starts the registration process.

To see those classes take a look at the source here: http://www.neosavvy.com/svn/neosavvy/projects/commons-user/trunk/commons-user-flex-client/src/main/flex/com/neosavvy/user/registration/

Testing and Verification

Now that the Flex Client is defined you can test to see if the code is working. To explore my example follow the instructions below. Hopefully the guide above and the code samples will be enough to help you get going with a similar setup.

1. Place the settings.xml from my SVN location into your ~/.m2/ directory from here: http://www.neosavvy.com/svn/neosavvy/projects/commons-user/trunk/settings.xml
2. Checkout the source code with the following command:
   svn co http://www.neosavvy.com/svn/neosavvy/projects/commons-user/trunk/ commons-user
3. Change directory into your commons-user directory and run a maven clean install
   mvn clean install
4. Wait until the code compiles and test cases complete. The build should be successful.
5. Change directories into the commons-user-webapp and start the application served
   cd commons-user-webapp ; mvn cargo:start
6. The server should start then you can open your browser and navigate to http://localhost:8080/commons-user-webapp/
7. Click the button at the top of the Application
8. Notice that you can being the registration flow and create a user
9. After completing the registration you should notice that your user has been added to the grid.

Click here to see full image

This concludes the simple BlazeDS integration with Spring Flex. In a future post I will explore the hooks into Spring Security for Spring Flex. Also will explore the restriction of some of the administrative features such as deleting a user and viewing/searching users.

Thanks for reading! Please email me at aparrish@neosavvy.com if you have any questions. Also please feel free to comment on this post and ask questions.

If you are interested in seeing part two of this post please click here