GWT and Spring Security

Update: I have put together a sample app to demonstrate the integration technique: http://seewah.blogspot.com/2009/06/gwt-and-spring-security-sample-demo.html

As promised, I am posting this article to share my experience with using Spring Security (formerly ACEGI) with GWT. Apologies for the delay. I guess I have just been busy + lazy!

First of all, for those of you who haven't, please read my previous blogs GWT Spring Integration and GWT Spring Integration - using ContextLoaderListener to see how to use Spring-managed service beans in GWT.

Again it is not my intention to provide a complete solution for GWT / Spring Security integration as there are so many ways of doing it, and which method to choose depend hugely on how you want to actually use Spring Security inside GWT. By sharing my limited experience here, I hope to give some ideas to those of you who are trying to come up with a solution that fits your needs.

So how do I want to use Spring Security in my GWT application?

I want to:

1) leverage Spring Security's SecurityContext mechanism to store authenticated token, which I can then access anywhere in my code
2) be able to annotate my service classes, so that Spring can apply method security using AOP to my service beans

I DO NOT want to:

1) let Spring Security automatically handle form authentication for me
2) rely on Spring Security to automatically redirect user to login page

In other words, using Spring Security, I want to develop some form of RPC service which my GWT client can call to authenticate the username and password supplied by the user at the login screen. Once authentication has succeeded, a token which identifies the current user as being authenticated will be available to all subsequent RPC requests, so that I can either manually inspect the token inside the RPC request to enforce some form of authorization, or I can rely on Spring Security's off-the-shelf method security mechanism to allow or disallow user call certain methods in my Spring managed service beans.

I am going to break up the rest of the article into three different sections: An authentication service, HTTP Session Integration and Method Security

An Authentication service

The following is a simple implementation of such a service:

import org.springframework.security.Authentication;
import org.springframework.security.context.SecurityContext;
import org.springframework.security.context.SecurityContextHolder;
import org.springframework.security.context.SecurityContextImpl;
import org.springframework.security.providers.UsernamePasswordAuthenticationToken;
import org.springframework.security.userdetails.User;

public class AuthenticationServiceImpl implements AuthenticationService {

 /**
  * Authenticates against the supplied credentials,
  * populating the Spring SecurityContext if
  * credentials are OK.
  *
  * @param username
  * @param password
  * @return
  *     whether authentication is successful
  */
 public boolean authenticate(String username, String password) {
 
     // check credentials, e.g., by querying a database...
     boolean authenticated = checkCredentials();

     // look up authorities by, e.g., querying the database...
     GrantedAuthority[] authorities = getGrantedAuthorities(username);
 
     if (authenticated) {
         User user = new User(username, password, true, true, true, true, authorities);
         Authentication auth = new UsernamePasswordAuthenticationToken(user, password, authorities);
         SecurityContext sc = new SecurityContextImpl();
         sc.setAuthentication(auth);
         SecurityContextHolder.setContext(sc);
     }

     return authenticated;
 }

 public void logout() {
     SecurityContextHolder.clearContext();
 }
}

This of course is a very simple implementation, but the point to note is within the authenticate method, an Spring Authentication object is created and inserted into the SecurityContext programmatically.

We can simply turn this into a RPC service by creating a com.google.gwt.user.server.rpc.RemoteServiceServlet implementation in which we either access AuthenticationServiceImpl directly or via a Spring ApplicationContext as described in my previous blogs GWT Spring Integration and GWT Spring Integration - using ContextLoaderListener.

Now we have a service that effectively let us "log into" the system. However, this on its own is rather useless, as the token is not available to subsequent request threads. If we have a RPC service for retrieving documents, and we would like to protect the documents, we really would want to be able to, inside the service, inspect the SecurityContext to see whether an authenticated token exists. We want be able to do the following, which we cannot do... yet:

if (SecurityContextHolder.getContext() == null
 SecurityContextHolder.getContext().getAuthentication() == null
 !SecurityContextHolder.getContext().getAuthentication().isAuthenticated) {

 // no authenticated token found, stop user from retrieving documents
}

HTTP Session Integration

Luckily, Spring Security provides a filter, org.springframework.security.context.HttpSessionContextIntegrationFilter, which automatically synchronises the current SecurityContext with a http session object, thus, making the token available to all subsequent request threads.

We can enable this filter in a number of ways. We can create the filter directly in web.xml (host-mode or standalone mode). Or we can create a org.springframework.security.util.FilterToBeanProxy in web.xml and define a FilterChainProxy in the Spring ApplicationContext. Or we can, as most people do nowadays, create a org.springframework.web.filter.DelegatingFilterProxy called springSecurityFilterChain (note: the naming is crucial) in web.xml and use Spring Security Namespace Configuration in the ApplicationContext to create the necessary beans. We will have a look at this last approach.

In web.xml

<filter>
 <filter-name>springSecurityFilterChain</filter-name>
 <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
</filter>

<filter-mapping>
 <filter-name>springSecurityFilterChain</filter-name>
 <url-pattern>/*</url-pattern>
</filter-mapping>

<listener>
 <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
<listener>

<listener>
 <listener-class>org.springframework.security.ui.session.HttpSessionEventPublisher</listener-class>
</listener>

In Application Context:

<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:security="http://www.springframework.org/schema/security"....>

 <security:http entry-point-ref="dummyEntryPoint" create-session="always" />

 <bean id="dummyEntryPoint" class="com.seewah.blog.DummyEntryPoint" />
...
<beans>

This is pretty neat, except for the fact that we have to create a "dummy" org.springframework.security.ui.AuthenticationEntryPoint, even though we are not replying on Spring Security to redirect user to login page. Unfortunately, by design, the security:http tag requires an AuthenticationEntryPoint, so I created this class:

public class DummyEntryPoint implements AuthenticationEntryPoint {

 public void commence(ServletRequest request, ServletResponse response, AuthenticationException e) throws IOException, ServletException {
 
     throw new IllegalStateException("This implementation is a dummy class, created purely so that spring security namespace tags can be used in application context, and this method should never be called");
 }
}

OK, so now we have a way to "log into" the system, and we can inspect the SecurityContext in subsequent RPC requests to grant or deny users access to certain services. However, we would like to go one step further. We would like to leverage the excellent method security feature provided by Spring Security because we like our security layer to be non-invasive, and we like AOP.

Method Security

We configure method security as follows:

In Application Context:

<security:global-method-security secured-annotations="enabled" jsr250-annotations="disabled" />

<bean id="dummyAuthenticationProvider" class="com.seewah.blog.DummyAuthenticationProvider">
 <security:custom-authentication-provider />
</bean>

Unfortunately, again, because of the way Spring Security Namespace Configuration works, we have to introduce another dummy class, even though it will never be used. Remember our AuthenticationServiceImpl creates authenticated token programmatically and method security will simply grant / deny access based on the presence of this token. Hence the authencationProvider here becomes redundant. We implement the dummy class as follows:

public class DummyAuthenticationProvider implements AuthenticationProvider {

 public Authentication authenticate(Authentication authentication) throws AuthenticationException {
 
     throw new IllegalStateException("This implementation is a dummy class, created purely so that spring security namespace tags can be used in application context, and this method should never be called");
 }

 @SuppressWarnings("unchecked")
 public boolean supports(Class clazz) {
 
     throw new IllegalStateException("This implementation is a dummy class, created purely so that spring security namespace tags can be used in application context, and this method should never be called");
 }
}

Of course, as method security is implemented using AOP in Spring, only Spring-managed beans are protected, which means in order to use this mechanism to protect our service layer, we MUST access these services via the Spring ApplicationContext (GWT Spring Integration and GWT Spring Integration - using ContextLoaderListener) and NOT directly.

When a protected method is accessed without an authenticated token being present in the SecurityContext, Spring throws a SpringSecurityException. If we let this exception propagate all the way to the GWT client code, we are most certainly going to be greeted with the dreaded SerializableException error. Instead we should catch this exception and rethrow an exception that GWT can safely serialize and pass to the client side. We define such an exception, ServiceSecurityException, in our GWT client package, and now we have a mechanism that translates a Spring Security method security exception into a GWT client exception:

On the server

public class DocumentServiceImpl implements DocumentService {

 @org.springframework.security.annotation.Secured("ROLE_ADMIN")
 public void delete(Long id) {
     ...
 }
}

public class DocumentServiceServlet extends DependencyInjectionRemoteServiceServlet implements ... {

 @Autowired
 private DocumentService documentService;

 public void delete(Long id) throws ServiceSecurityException {
     try {
         documentService.delete(id);
     } catch (SpringSecurityException e) {
         throw new ServiceSecurityException(e.getMessage());
     }
 }
 ....
}

Inside the client

documentServiceAsync.delete(id, new AsyncCallback<Object>() {
 public void onFailure(Throwable throwable) {
     if (throwable instanceof ServiceSecurityException) {
         // client side logic to redirect user to login page, for example
     } else {
          ...
     }
 }
 ...
});

Of course, seeing that we need client-side exception handling whenever we invoke an "secured" RPC call, we may as well create an AutoErrorHandlingAsyncCallback and invoke all our RPC calls passing through an instance of this callback instead of the normal AsyncCallback object:

public abstract class AutoErrorHandlingAsyncCallback<T> implements AsyncCallback<T> {

 final public void onFailure(Throwable throwable) {    
     if (throwable instanceof ServiceSecurityException) {
         // client side logic to redirect user to login page, for example
     } else {
          ...
     }
 }
}

OK this way of using Spring Security method security is not as non-invasive as we have perhaps hoped, but IMHO this is far better than writing code to check for authenticated token in SecurityContext in the services themselves.