How to make Acegi work on Sun Application Server 8.x?

We are currently developing an application that employs Acegi and runs on Sun Application Server 8 (Sun AS 8.x).

Being a mature and widely adopted security solution, we did not have many problems until we encountered the following puzzling exception:

[#|2008-01-18T16:58:28.984+1100|SEVERE|sun-appserver-pe8.2|javax.enterprise.system.container.web|_ThreadID=22;|ApplicationDispatcher[/express_portal] Servlet.service() for servlet jsp threw exception
java.lang.ClassCastException: org.acegisecurity.providers.UsernamePasswordAuthenticationToken
at com.sun.web.server.J2EEInstanceListener.handleBeforeEvent(J2EEInstanceListener.java:130)
at com.sun.web.server.J2EEInstanceListener.instanceEvent(J2EEInstanceListener.java:68)
at org.apache.catalina.util.InstanceSupport.fireInstanceEvent(InstanceSupport.java:300)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:712)
at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:482)
at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:417)
at org.apache.catalina.core.ApplicationDispatcher.access$000(ApplicationDispatcher.java:80)
at org.apache.catalina.core.ApplicationDispatcher$PrivilegedForward.run(ApplicationDispatcher.java:95)
at java.security.AccessController.doPrivileged(Native Method)
at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:313)
at org.acegisecurity.ui.AccessDeniedHandlerImpl.handle(AccessDeniedHandlerImpl.java:65)
at org.acegisecurity.ui.ExceptionTranslationFilter.handleException(ExceptionTranslationFilter.java:166)
at org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:118)
at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
at org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125)
at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
at org.acegisecurity.wrapper.SecurityContextHolderAwareRequestFilter.doFilter(SecurityContextHolderAwareRequestFilter.java:81)
at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:217)
at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
at org.acegisecurity.ui.logout.LogoutFilter.doFilter(LogoutFilter.java:106)
at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:229)
at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
at org.acegisecurity.concurrent.ConcurrentSessionFilter.doFilter(ConcurrentSessionFilter.java:95)
at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
at org.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:148)
at org.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:98)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:210)
at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:55)
at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:161)
at java.security.AccessController.doPrivileged(Native Method)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:263)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:551)
at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:225)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:173)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:551)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:170)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:551)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:132)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:551)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:933)
at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:189)
at com.sun.enterprise.web.connector.grizzly.ProcessorTask.doProcess(ProcessorTask.java:604)
at com.sun.enterprise.web.connector.grizzly.ProcessorTask.process(ProcessorTask.java:475)
at com.sun.enterprise.web.connector.grizzly.ReadTask.executeProcessorTask(ReadTask.java:371)
at com.sun.enterprise.web.connector.grizzly.ReadTask.doTask(ReadTask.java:264)
at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:281)
at com.sun.enterprise.web.connector.grizzly.WorkerThread.run(WorkerThread.java:83)
|#]

We traced the application server and found that it was likely caused by the Sun AS 8.x trying to cast the Acegi-implemented Principal to an internal Sun AS implementation.

We did some googling and found that Andrey Grebnev blogged about this two years ago, and he suggested a workaround by overriding the getUserPrincipal() method (of SecurityContextHolderAwareRequestWrapper) by always returning a null.

Because SecurityContextHolderAwareRequestWrapper and its subclasses are used internally by Acegi, his workaround implied changing the source code of Acegi, which we are reluctant to do.

Realizing that the it was only unsafe for the HttpServletRequest to return the Acegi-implemented Principal when the servlet filter chain has been executed and the control is handed over to the AS and the running application, we came up with a NullPrincipalFilter that wraps the incoming HttpServletRequest with a NullPrincipalHttpServletRequestWrapper, which returns null for getUserPrincipal(), and hands the control over to the AS. This filter should always be placed at the end of the filter proxy chain in Acegi. And of course, the application must not use HttpServletRequest's getUserPrincipal() method to retrieve the user principal, which is very easy to do, as it can invoke SecurityContextHolder.getContext().getAuthentication() to achieve the same goal, without coupling to the Servlet API.

The following is the source code of NullPrincipalFilter:

package au.net.ozgwei.util.httpservlet;

import java.io.IOException;

import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletRequestWrapper;

import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;

/**
 * A filter designed specific to get around the bug in Sun Application Server
 * 8.x where a custom security framework's implementation of Principal is
 * casted to Sun Application Server's own implementation.
 *
 * @author Alex
 * @version 1.0
 */
public class NullPrincipalFilter implements Filter {

 @SuppressWarnings("unused")
 private static final Log log = LogFactory.getLog(NullPrincipalFilter.class);

 /* (non-Javadoc)
  * @see javax.servlet.Filter#destroy()
  */
 public void destroy() {
 }

 /* (non-Javadoc)
  * @see javax.servlet.Filter#doFilter(javax.servlet.ServletRequest, javax.servlet.ServletResponse, javax.servlet.FilterChain)
  */
 public void doFilter(ServletRequest aRequest, ServletResponse aResponse, FilterChain aFileterChain) throws IOException, ServletException {
     aFileterChain.doFilter(
         new NullPrincipalHttpServletRequestWrapper(
             (HttpServletRequest) aRequest), aResponse);
 }

 /* (non-Javadoc)
  * @see javax.servlet.Filter#init(javax.servlet.FilterConfig)
  */
 public void init(FilterConfig aArg0) throws ServletException {
 }

}

And the source code of NullPrincipalHttpServletRequestWrapper:

package au.net.ozgwei.util.httpservlet;

import java.security.Principal;

import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletRequestWrapper;

import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;

/**
 * A HttpServletRequestWrapper that always return null for Principal.
 *
 * @author Alex
 * @version 1.0
 */
public class NullPrincipalHttpServletRequestWrapper extends HttpServletRequestWrapper {

 @SuppressWarnings("unused")
 private static final Log log = LogFactory.getLog(
        NullPrincipalHttpServletRequestWrapper.class);

 public NullPrincipalHttpServletRequestWrapper(HttpServletRequest aReq) {
     super(aReq);
 }

 @Override
 public Principal getUserPrincipal() {
     return null;
 }

}

And a nullPrincipalFilter bean should be defined in the Spring application context and added to the end of the filterChainProxy, as following:

<bean class="org.acegisecurity.util.FilterChainProxy" id="filterChainProxy">
 <property name="filterInvocationDefinitionSource">
     <value>
         CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON
         PATTERN_TYPE_APACHE_ANT
         /**=concurrentSessionFilter,httpSessionContextIntegrationFilter,logoutFilter,authenticationProcessingFilter,securityContextHolderAwareRequestFilter,anonymousProcessingFilter,exceptionTranslationFilter,filterInvocationInterceptor,nullPrincipalFilter
     </value>
 </property>
</bean>

<bean class="au.net.ozgwei.util.httpservlet.NullPrincipalFilter" id="nullPrincipalFilter">

Finally, this bug has been fixed in GlassFish eventually.

Gavin King: first impression (contrasting Spring guys)

Today I attended Red Hat's "Gavin King" event. While I have attended many Spring events in Sydney, this is my first time attending a Hibernate/JBoss/Red Hat event. And the impressions are quite different...

• First impression - clothes:
• The Spring guys are always well-suited and businessmen-like. They are often the centre of the crowd.
• Gavin's clothes were the most casual in the room. Before his presentation, I thought that fitted T-shirt wearing guy in trendy jeans was some skateboarding Ruby programmer who happened to want to know something in the Java world...
• Presentation style:
• The presentations by the Spring guys are always very professional, with the right level in technology details according to the nature of the event, the structure well organised, and seemingly well rehearsed.
• Gavin's presentation is, again, more casual, just like a technology chat. I don't know how much the other people in the audience know about Web Beans and Seam, but Gavin lost me a few times because I haven't been following what's happening in the JBoss world...
• Technology inclination:
• The Spring guys can be very pedantic (in a good way), always emphasising best practices, such as programming to interfaces, abstraction levels, separation of concerns, etc.
• Gavin is more pragmatic. Interfaces did not even make it to his slides. His Web Beans JSR recommends to make business interface optional for EJB 3.1 in Java EE 6. He reckons AOP is too complex for ordinary Java developers, there are only a handful of cross-cutting concerns, and EJB interceptors are enough to get the job done.
• Spring framework focuses on enterprise applications that are typically developed by financial institutions and usually involves lots of web services and enterprise application integration, and some of these enterprise applications may not even have a web tier.
• Web Beans JSR, JBoss Seam and Rich Faces, promoted by Gavin, are all mostly relevant to web-focused projects. Web Beans and JBoss Seam are particularly designed to ease development burden on entity management website with lots of CRUD operations, which make them competitors of (J)Ruby on Rails and Grails. I'll try to compare these frameworks in a later post. Enterprise applications seem off the target.
• The apparent weakness in the Spring framework are: no type-safety check in the application context until runtime, verbose XML configuration, no bean id (or name) namespaces and the statelessness of Spring-managed beans. However, the first two have been addressed by JavaConfig and XML namespace. Noticeably, JavaConfig also uses annotations, but only in the config class without polluting the service bean or the service client. The stateless singleton issue has also been tackled with 'scopes' and domain object dependency injection, which is enabled by Spring AOP.
• Gavin loves type-safety check in Java, so he hates the lack of type-safety check in Spring XML configuration, and he embraces annotation wholeheartedly. So he prefers Google Guice to Spring for dependency injection. In contrast to Spring's JavaConfig, Google Guice's annotations are used everywhere, in the service bean, in the service client or both. JBoss Seam introduces lots of annotations, and Web Beans JSR is to make many of these annotations into Java EE standard. I don't remember how many times Gavin showed the definition of an annotation in his slides today. Probably a dozen! And he still relies on XML configuration to override annotations. He classifies services beans according to deployment, such as one for production, one for stubbing in testing. So what will you do if you have two classes with the same service API, both used in production environment? My guess is you need to write a new annotation to differentiate them... Seems overuse of annotations, doesn't it?
• Hostility:
• Spring guys rarely publicly show their hostility towards JBoss, though in after session chats, they describe JBoss Seam as a "big hack", "annotation hell", "technologically inferior" and "would have been just another web framework were it not for Gavin King's fame".
• Gavin is more straight forward, rubbished Spring guys as "AOP nerds" during the session, and I wouldn't be surprised if he called Spring "XML hell". He deliberately omitted Spring when he enumerated the open source frameworks that have influenced Java EE.
• The audience:
• Spring events usually draw a huge audience. Many times, some people who came late had to stand in the back of the room for the whole session. They are almost always held in the evening.
• Today's Hibernate event was held in the morning with only a few dozen people attending. One-third of the seats were empty.

Anyway, I was pretty impressed by Gavin's demo of fast web project development with JBoss AS, JBoss Seam, Rich Faces and JBoss Tools. I'll definitely give it a try when I have the time...