AOP is a way to modularize cross-cutting concerns. Ok, what does “modularize” really mean? Modularization is the encapsulation of a unit of functionality. It is exactly what “Class” is doing in OO world. How about “cross-cutting concerns”? Basically it means any functionalities that span multiple modules/ classes. They include Transaction Management, Security, Caching, Performance Monitoring and etc. To understand how AOP works, we first look at the common terms in this area:

1. Join point – An identifiable point in the execution of a program like method invocation, exception thrown.
2. Pointcut – Program construct that selects join points and collects context at those points. AspectJ has a rich pointcut expression language!
3. Advice – Code to be executed at a join point that has been selected by a pointcut.

To me, I found it easier to understand these terms if I consider join point as event generated point in code, pointcut as a way to define what events to be captured and advice as event handler.

AOP is indeed a powerful way to factor out system or infrasturcture-related code from the business oriented code. Typically, we use it to take care of transaction, security and profiling aspects. But it doesn’t stop you putting creativity in this domain. With a bit more creativity, you can also do the following::

1. Exception translation – checked to runtime
2. Catch ConcurrencyFailureExceptions and transparently retry if an idempotent operation fails with, for example, a deadlock loser exception.

How I use Spring AOP in my project?

I have been told to report the elapsed time for all calls to the database. If I don’t know how to use AOP, I may end up putting code to measure time for every JDBC calls. It ends up tangling performance monitoring code with my main line business logic and the same logic will be scattered everywhere in my data access code. Bad!! That is why we need to know how to factor out the performance monitoring code into an aspect like below:

Here we use AspectJ annotation approach to implement the aspect. “Around” is to intercept start and end of any repository method. Here is what states in Spring 2.5 reference:

Spring 2.0 introduces a simpler and more powerful way of writing custom aspects using either a schema-based approach or the @AspectJ annotation style. Both of these styles offer fully typed advice and use of the AspectJ pointcut language, while still using Spring AOP for weaving.

If you use AspectJ annotation, you need to put <aop:aspectj-autoproxy/> in your application-context.xml. The limitation of Spring proxy-based AOP is that it is limited to method invocation interception. To get around that, you can use AspectJ syntax in your pointcut expression. You don’t need to build the application with ajc (the AspectJ compiler) even you are using AspectJ syntax. Spring AOP can also understand @AspectJ aspects. I strong suggest you use Annotation driven AOP because it is cleaner and simplier. Working with AOP, I have faced 2 questions.

1. How to select the methods that I want to intercept without hardcoding the method or package name in my pointcut expression. So, my aspect or pointcut doesn’t contain application specific information – Look into annotation and AOP section.
2. How to turn on and off AOP without restarting the web application? I would use JMX. Look into “What is JMX” section. 

Annotation and AOP

Annotation provides a better way other than code signature for selecting join point that leads to creating loosely coupled aspect. In fact, you can see annotation as another signature of a method in other dimension. And a method can have multiple annotations and each concern just bother its own annotation. It is called multidimensional signature space. For example,

@Authentication(“bankOperation”)
@Transactional(REQUIRED)
public void credit(){…}

Pointcut uses annotation to capture join points. For example:

execution(@Transactional * *.*(..)) Execution of a method annotated as Transactional
execution((@Trasactional *) *.*(..)) Execution of a method that returns object annotated as Transactional
execution(* (@Transactional *).*(..)) Execution of a method defined for type annotated as Transactional

Selection can use Annotation types and Annotation values.  What is more, annotation values can be used in Advice implementation.

Here is a great video from Parleys that talked about “Leveraging Annotation with AOP”. I have included some key points Ramnivas made here:

• Write you pointcut in a smart way to avoid annotation mess. Try to use naming and package convention to help you. For example, if you want to write app log for all public facing service method, you can use “public” with package name containing “service” wildcard to help you.
• If you really need to use annotation like @Transaction that designer has no way to define the pointcut beforehand, use annotation to describe what the join point is but not how to handle it. So, your transaction aspect only need to worry annotation @Transaction and decouple from the application.
• You can piggyback annotation. For example, you can make all entities auditable via declare @type: @Entity *: @Auditable; 

How does Spring AOP work internally?

The magic behind AOP is the concept of Proxy/ Decorator/ Interceptor/ Filter pattern. To me, all those patterns are conceptually the same. They all try to present itself as target object (thru implementing the same interface), intercept method call and execute injected logics. And you can have more than one interceptors invoked in series. In Spring AOP, there is one thing we need to pay attention:

However, once the call has finally reached the target object, …any method calls that it may make on itself, such as this.bar() or this.foo(), are going to be invoked against the this reference, and not the proxy. This has important implications. It means that self-invocation is not going to result in the advice associated with a method invocation getting a chance to execute. To handle this, either you refactor your code such that the self-invocation does not happen (best approach) or you make self invocation call thru proxy like ((Pojo) AopContext.currentProxy()).bar() (invasive approach b/c it totally couples your code to Spring AOP, and it makes the class itself aware of the fact that it is being used in an AOP context, which flies in the face of AOP. Avoid using it).

However, it must be noted that AspectJ does not have this self-invocation issue because it is not a proxy-based AOP framework.

What is JMX?

In short, it is a way to enable management and monitoring of Java applications over a generic API. JMX has a simple architecture that contains instrumentation level, agent level and distribution service level. In instrumentation layer, we register MBean to the MBeanServer. In simple term, In simple term, MBean is a  JavaBean with defined management interface that exposes attributes and operations to the world. MBeanServer acts as a broker to decouple communication among application MBeans and/or remote clients.

Combine AOP and JMX

AOP is statically defined and intercept at the runtime. It is hard to take this out or add another aspect in after you start your machine. However, with JMX, you can enable and disable it via skipping the aspect code. On the other hand, you can also use JMX to configure and report SLA metrics like configure thresholds and send notifications of violations. That sounds very interesting to me. There are other interesting usages mentioned in the Parley’s video as well:

1. Service blocking – throw an exception if particular service you don’t want to user to use it for a period of time esp during maintenance time.
2. Caching management – I am currently using interceptor pattern and IoC to intercept dao method calls for cache lookup. 

Reference

1. JavaOne 07 – JMX, AOP and Spring (Nice Presentation)
2. Parley’s AOP and JMX (Video)
3. Simplifying Enterprise Applications with Spring 2.0 and AspectJ
4. Workflow Orchestration Using AOP
5. Performance Monitoring with AOP and JMX

My Web application needs both authentication and role-based authorization features. And our user profile is currently stored in an OpenLDAP server. I am looking for a security framework that can help me to integrate LDAP and provide these security features with the least amount of effort. On top of that, I want to achieve this without polluting my business logic with security code (ie. via AOP). At my first glance, Spring security (aka. acegi security) looks promising to me. After evaluating it a bit more, I believe it does provide what I need for my project. So, I started creating a prototype and gave it a trial. In this article, I will go over the steps I took to build my prototype and I will provide you the necessary explanation to move forward alongside. Hopefully, you will get over the initial learning curve as quick as possible with this guide.

Spring Security Overview

Step 1. Specify the location of the configuration files for Spring and Log4J in web.xml

The configuration below tells Spring and Log4J the location of the configuration files. These files will be parsed by the ContextLoaderListener (for Spring) and Log4JConfigListener (for log4j) during the initial loading process.

<context-param>
  <param-name>contextConfigLocation</param-name>
  <param-value>/WEB-INF/applicationContext.xml</param-value>
</context-param>

<context-param>
  <param-name>log4jConfigLocation</param-name>
  <param-value>/WEB-INF/classes/log4j.properties</param-value>
</context-param>

Step 2. Define the Acegi Filter Chain Proxy Filter in web.xml

Spring Security’s support for web security is heavily based on servlet filters. These filters intercept an incoming request and apply some security processing before the request is handled by your application. Spring security comes with a handful of filters that intercept servlet requests and pass them on to the authentication and access decision manager to enforce security. However if you ever used servlet filters, you know that for them to take effect, you must configure them in the web application’s web.xml file, using the <filter> and <filter-mapping> elements. While this works, it doesn’t lend itself to configuration using dependency injection. You have no control of the life-cycle of the filter (like instantiation), but you may be able to override the constructor and use WebApplicationContextUtil to load the bean your filter needs to act on. This is not ideal as you need to hardcode a reference to the name of the bean. That is why Filter Chain Proxy is created. The FilterToBeanProxy is a special servlet filter that, by itself, doesn’t do much. Instead, it delegate its work to a bean implements the Filter interface just like other servlet filter. In the configuration below, the target class is the filter class that I talk about. Using this approach, Spring security is able to plug in its security functionality in a modular way. NOTE: The mechanism is not Spring Security specific. You can use this approach if you have no control of the life-cycle of the class you are interested in.

   <filter>
        <filter-name>Acegi Filter Chain Proxy</filter-name>
        <filter-class>net.sf.acegisecurity.util.FilterToBeanProxy</filter-class>
        <init-param>
            <param-name>targetClass</param-name>
            <param-value>net.sf.acegisecurity.util.FilterChainProxy</param-value>
        </init-param>
   </filter>

Step 3. Define the Filter chain in ApplicationContext.xml

Now you have the proxy to redirect the request to your Spring bean. What is next? Spring Security requires at least 4 filters to be functioned. Does this mean that you have to configure a FilterToBeanProxy for each of the filters. No! To make life easier, Spring Security offers "FilterChainProxy" that can be configured to chain together several filters at once. The filters we need as part of the request processing are:

1. HttpSessionContextIntegrationFilter
   • Check to see if the user’s Authentication information is in Session. If so, it makes the authentication info available to the current request. At the end of the request, it will deposit the authentication info back into the session so that it will be available for the next request.
   • It prevents user from logging in again.
2. AuthenticationProcessingFilter
   • Delegate to AuthenticationManager to do the actual authentication. AuthenticationManager determines who you are. Once you are identified, a list of roles that belongs to you will be populated. As with the rest of Spring Security, the authentication manager is a pluggable interface-based component. This makes it possible to use Spring Security with virtually any authentication mechanism.
   • Process authentication based on username and password given to it in j_username and j_password.
   • "filterProcessesUrl" property tells which URL it should intercept. Default to /j_acegi_security_check.
   • "authenticationFailureUrl" property indicates where the user will be sent should authentication fail.
   • When authentication is successful, Authentication object will be placed to the Session.
3. ExceptionTranslationFilter
   • Handle AuthenticationException via sending the user to the authentication entry point. It is configured in the "authenticationEntryPoint" property. There are different type of entry points: Basic, Form, Digest and X.509 cert.
   • Handle AccessDeniedException - Default to HTTP 403 error to the browser. You can configure AccessDeniedHandlerImpl to forward the user to nice-looking error page.
   • Without anything to handle Spring Security exceptions above, they would flow up to the servlet container and be displayed in the browser as stack trace.
4. FilterSecurityInterceptor
   • Enforce web security. If user has not been authenticated, throw an AuthenticationException which will be handled by exception translation filter. If user has no right to access the resource, it will throw an AccessDeniedException that will be handled by exception translation filter as well.
   • It is wired with authenticationManager and accessDecisionManager
   • Access Decision Manager determines whether you are authorized to access the secured resource. It performs authorization, deciding whether to let you in by considering your authentication information and the security attributes that have been associated with the secured resource. Access Decision Manager is also pluggable.
   • "objectDefinitionSource" property specifies which resources (ie. urls) are secured and what privileges are required to access them via url pattern with roles.
5. ChannelProcessingFilter (optional)
   • Even you have done all the secure protection as stated above, the information you are authorized to obtain still needs to transfer to you via the Internet unprotected. You may want to encrypt it to prevent people from stealing it. Use HTTPS!
   • ChannelProcessingFilter offers a foolproof way to ensure that certain pages be transferred using HTTPS via intercept the request, check to see if it needs to be secure and, if so, call https by redirecting the request to an HTTPS form of the original request URL.

NOTE: "securityEnforcementFilter" can combine ExceptionTranslationFilter and FilterSecurityInterceptor together.

To chain them up, here is the xml piece for FilterChainProxy.

<bean id="filterChainProxy" class="net.sf.acegisecurity.util.FilterChainProxy">
      <property name="filterInvocationDefinitionSource">
         <value>
      CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON
      PATTERN_TYPE_APACHE_ANT
      /**=httpSessionContextIntegrationFilter, authenticationProcessingFilter, exceptionTranslationFilter, filterSecurityInterceptor
         </value>
      </property>
    </bean>

You can put more than 1 pattern if you want. The order of the filters are important because it governs the order of the filters in the chain.

Step 4. Customize the authentication mechanism

Now you have all the filters wired. You may want to provide a custom authentication against your own database or ldap server. To do that, you need to implement UserDetail class and wire it up with authentication manager. Below is the method you need to override.

public UserDetails loadUserByUsername(String userId) throws UsernameNotFoundException, DataAccessException {
        User user = null;
        GrantedAuthority[] grantedAuthorities = null;
        try {
            user = getUserDAO().lookupUser(userId);
            
            if(user==null) {
                throw new UsernameNotFoundException("Invalid User");            
            }
            
            Set roles = user.getRoles();
            int i = 0;
            grantedAuthorities = new GrantedAuthority[roles.size()];
            for (Iterator iter = roles.iterator(); iter.hasNext(); i++) {
                Role role = (Role) iter.next();
                
                GrantedAuthority authority = new GrantedAuthorityImpl(role.getRole());
                grantedAuthorities[i] = authority;
            }
        } catch (DataStoreException e) {
            throw new DataRetrievalFailureException("Cannot loadUserByUsername userId:"+userId+ " Exception:" + e.getMessage(), e);
        }

        UserDetails userDetails = new org.acegisecurity.userdetails.User(
                user.getUserId(), 
                user.getPassword(),
                user.isEnabled(), //enabled
                user.isEnabled(), //accountNonExpired
                user.isEnabled(), //credentialsNonExpired
                user.isEnabled(), //accountNonLocked
                grantedAuthorities
                );
        return userDetails;
    }

Now you need to wire it up to your Authentication Manager

<bean id="authenticationManager" class="org.acegisecurity.providers.ProviderManager">
  <property name="providers">
   <list>
    <ref local="daoAuthenticationProvider"/>
   </list>
  </property>
</bean>

<!-- Acegi will use our UserService bean to do authentication -->
<bean id="daoAuthenticationProvider" class="org.acegisecurity.providers.dao.DaoAuthenticationProvider">
  <property name="userDetailsService"><ref bean="UserService"/></property>
  <property name="passwordEncoder"><ref local="passwordEncoder"/></property>
</bean>

<bean id="UserService" 
      class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean">
  <property name="transactionManager">
    <ref bean="myTransactionManager"/>
  </property>
  <property name="target">
    <bean class="com.solutionhacker.user.UserServiceImpl" >
      <property name="userDAO">
        <ref local="UserDAO" />
      </property>
    </bean>
  </property>
  <property name="transactionAttributes">
    <props>
      <prop key="*">PROPAGATION_REQUIRED,-Exception</prop>
    </props>
  </property>
</bean>

View-layer security

 As you may notice, filters only provide a coarse-grained security, limiting access at the request level like either you can access the resource or not. In some cases, you may want more fine-grained control over what the user is allowed to see. Maybe all users of an application will be allowed to see a certain page, but only users who are granted special authority may see certain elements on that page. To handle this, Spring Security uses JSP tag library. This tag library provides only 3 tags: <authz:acl>, <authz:authentication> and <authz:authorize>. You can use this tag to wrap around the UI element and conditionally allows it to display or not based on the role. I will not go through the detail of this here. Since I advocate to use Flex as View, so I will write another article to talk about how we can achieve it in Flex.

Secure method invocation

 Similar

Conclusion

As you can tell, you don’t write much java code to protect your resource. Everything is almost driven by configuration there. It is nice. However, on the other hand, the tedious work is shifted to configuration. To me, reading the configuration is harder than reading code. You can tell most of the configuration there are not coupled with application. Only the section that is application specific is the security policies you put in under "objectDefinitionSource".  Again, to associate all the stuff I want to protect with the role names are tedious and hardcoded.

UPDATE: Acegi is moved to Spring Security 2.0 that has new namespace for security. The main thing they fix is to make the configuration much cleaner. I will talk about that in my next article.

UPDATE: Riable has walked us through how to upgrade from Acegi to Spring Security here. So, I don’t need to write one!

Reference

http://springtips.blogspot.com/search/label/security

http://i-proving.ca/space/Technologies/Acegi+Security+System+for+Spring

http://static.springframework.org/spring-security/site/reference/pdf/springsecurity.pdf