Secure Remoting with Spring and JBoss

If you are faced with having to write a rich client application in a multi-tier Java EE environment, you will typically connect to the application server over RMI. In theory, you are meant to use the servers Application Client Container and deploy your application as a client in that container. You probably won’t do that though, because the client container is unfriendly for many reasons:

1. As an example, the WebSphere 6.1 Client Container is a 200 megabyte install,
2. Client Containers tend to be started as batch commands which set up the environment in which your application will run. If you however have an application that is meant to be started with a sexy launcher, as is the case with Eclipse RCP applications, you will struggle to get the environment created properly by the launcher, and its not supported by the vendor anyway,
3. If you need to connect to the server securely (ie. so that serverside you have a valid security context allowing you to authorise users to call given services), then I personally have never been able to get the security callback mechanism to work. Theoretically you can tell the container to call your code at the point which it logs on to the server in order to get the credentials (eg. you can pop up a little login window),

For these reasons, I have never ever used a client container in a production environment. Instead I have repeatedly gone to the trouble of getting the client environment fit so that it can call the server over RMI with a security context. The problem is not only that this is painful, but that it is unsupported by the App Server vendor, and is almost guaranteed to break with the next release of the App Server, requiring further pain from a consultant in order to get be able to migrate to the next App Server version. Additionally, setting the environment for the Initial Context in a client, to connect to the server and find objects in the JNDI tree can be difficult and is often poorly documented (after all, you are meant to do it from inside the client container where you do not need to provide the environment yourself).

However, there is another way! In a previous article, I wrote about how I got an applet to send information back to the server by implementing a custom protocol containing serialised objects. In hindsight I discovered Hessian from Caucho which does a similar thing. Recently I have been looking into Spring which supports Hessian (Custom Binary over HTTP), Burlap (XML over HTTP) and its own kind of remoting, namely Java Serialisation over HTTP.

With little effort I was able to find out how to secure the HTTP connection with the server, meaning that I am now free to write an arbitrary rich client who can call services in a Java EE environment without the use of a Client Container, and without a non-supported RMI environment that is likely to not work after a server version migration. Woo Hoo! How? Easy, keep reading…

First, lets start with a little diagram:

This article won’t go into detail about how to create an RCP application or plugin, and will simply call the remote service from a simple Java application. The steps involved in getting to where we are going are:

1. Add a Datasource to JBoss
2. Add Security to JBoss (using the datasource, although LDAP would be an option too)
3. Create a Web Application containing the service implementation
4. Create a client capable of calling the remote service

1) Add a datasource to JBoss

For this article, JBoss 4.2.2 was used. To add a datasource, create a configuration file:

<JBoss-Home>/server/<instance>/deploy/mysql-ds.xml

where <instance> was “default” in the case of this example. This example uses MySQL 4.1. This configuration file should contain the following:
<?xml version=”1.0″ encoding=”UTF-8″?> <datasources> <local-tx-datasource> <jndi-name>jdbc/MySqlDS</jndi-name> <connection-url>jdbc:mysql://localhost:3306/test</connection-url> <driver-class>com.mysql.jdbc.Driver</driver-class> <user-name>user</user-name> <password>changeit</password> <exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.MySQLExceptionSorter</exception-sorter-class-name> <valid-connection-checker-class-name>org.jboss.resource.adapter.jdbc.vendor.MySQLValidConnectionChecker</valid-connection-checker-class-name> <check-valid-connection-sql>select 1</check-valid-connection-sql> <!– corresponding type-mapping in the standardjbosscmp-jdbc.xml –> <metadata> <type-mapping>mySQL</type-mapping> </metadata> </local-tx-datasource> </datasources>

A restart of JBoss will make this datasource available in JNDI under the name java:/jdbc/MySqlDS.

2. Add Security to JBoss

Add the following application policy to:

<JBoss-Home>/server/<instance>/conf/login-config.xml

<application-policy name=”SpringWeb”> <authentication> <login-module code=”org.jboss.security.auth.spi.DatabaseServerLoginModule” flag=”required”> <module-option name=”dsJndiName”>java:/jdbc/MySqlDS</module-option> <module-option name=”principalsQuery”> select password from users username where username=?</module-option> <module-option name=”rolesQuery”> select role, ‘Roles’ from roles where username=?</module-option> </login-module> </authentication> </application-policy>

Before it can work, you will need to add two tables to the database. The following is some SQL to do that:

create table users( username varchar(64), password varchar(64), primary key (username) ) type = innodb; create table roles( username varchar(64), role varchar(64), foreign key (username) references users(username), index (username) ) type = innodb; insert into users values(‘admin2’, ‘admin2’); insert into roles values(‘admin2’, ‘registered’);

3) Create Web App

To create the web application you need the following files:

web.xml contains:
<?xml version=”1.0″ encoding=”UTF-8″?> <web-app xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” xmlns=”http://java.sun.com/xml/ns/javaee” xmlns:web=”http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd” xsi:schemaLocation=”http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd” id=”WebApp_ID” version=”2.5″> <display-name>SpringWeb</display-name> <context-param> <param-name>contextConfigLocation</param-name> <param-value>/WEB-INF/applicationContext.xml</param-value> </context-param> <listener> <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class> </listener> <servlet> <servlet-name>remoting</servlet-name> <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class> <load-on-startup>1</load-on-startup> </servlet> <servlet-mapping> <servlet-name>remoting</servlet-name> <url-pattern>/remoting/*</url-pattern> </servlet-mapping> <security-constraint> <display-name>secure remoting</display-name> <web-resource-collection> <web-resource-name>secure</web-resource-name> <url-pattern>/secure/*</url-pattern> <url-pattern>/remoting/*</url-pattern> </web-resource-collection> <auth-constraint> <role-name>registered</role-name> </auth-constraint> <user-data-constraint> <transport-guarantee>NONE</transport-guarantee> </user-data-constraint> </security-constraint> <login-config> <auth-method>BASIC</auth-method> </login-config> <security-role> <role-name>registered</role-name> </security-role> </web-app>

In the above web.xml, I have configured a Spring ContextLoaderListener which uses the contextConfigLocation parameter to load the Spring configuration. A servlet has also been configured for the URL pattern “remoting” and this URL pattern has also been secured, requiring basic authentication in order to be requested.

remoting-servlet.xml contains:
<?xml version=”1.0″ encoding=”UTF-8″ ?> <beans> <bean name=”/TestService” class=”org.springframework.remoting.httpinvoker.HttpInvokerServiceExporter”> <property name=”service” ref=”testService”></property> <property name=”serviceInterface” value=”uk.co.maxant.test.spring.service.TestService”></property> </bean> </beans>

The above remoting-servlet.xml is firstly named after the dispatcher servlet which was defined in web.xml. Secondly, it defines the service exporter and our service that we wish to make remote, namely “TestService”. What is missing from the above is the definition of the “testService” bean. That definition is located under the applicationContext.xml:
<?xml version=”1.0″ encoding=”UTF-8″?> <beans xmlns=”http://www.springframework.org/schema/beans”> <bean id=”testService” class=”uk.co.maxant.test.spring.service.TestServiceImpl” ></bean> </beans> That bean definition could equally have actually been included in remoting-servlet.xml.
Finally, the jboss-web.xml file contains the link between the security policy that was added to login-config.xml, and the web application:
<?xml version=’1.0′ encoding=’UTF-8′ ?> <!DOCTYPE jboss-web PUBLIC “-//JBoss//DTD Web Application 2.3V2//EN” “http://www.jboss.org/j2ee/dtd/jboss-web_3_2.dtd”> <jboss-web> <security-domain>java:/jaas/SpringWeb</security-domain> </jboss-web>

Next, on the web app classpath, we need to have two classes, namely the service interface and its implementation.
package uk.co.maxant.test.spring.service; public interface TestService { public String sayHello(String s) throws Exception; } package uk.co.maxant.test.spring.service; import javax.naming.InitialContext; import uk.co.maxant.test.TestBeanLocal; public class TestServiceImpl implements TestService { public String sayHello(String s) throws Exception { //for example, we could call an EJB here InitialContext ctx = new InitialContext(); TestBeanLocal bean = (TestBeanLocal)ctx.lookup(“TestEAR/TestBean/local”); bean.doSomething(); return “hi there ” + s; } } The web application now contains everything it needs to go. Restart JBoss and deploy the web application to it.

4) Create Client
All that is now left is to create a client that can call the remote service. Create a project with the following files:

To start with, the applicationContext.xml is a Spring configuration and looks like this:
<?xml version=”1.0″ encoding=”UTF-8″?> <beans xmlns=”http://www.springframework.org/schema/beans”> <bean id=”basicAuthenticationInvokerRequestExecutor” class=”uk.co.maxant.spring.remoting.BasicAuthenticationInvokerRequestExecutor” > </bean> <bean id=”testService” class=”org.springframework.remoting.httpinvoker.HttpInvokerProxyFactoryBean”> <property name=”serviceUrl” value=”http://localhost:8080/SpringWeb/remoting/TestService” ></property> <property name=”serviceInterface” value=”uk.co.maxant.test.spring.service.TestService” ></property> <property name=”httpInvokerRequestExecutor” ref=”basicAuthenticationInvokerRequestExecutor” ></property> </bean> </beans>
In the Spring configuration above, the remote service is defined in terms of its URL and its interface class. The “basicAuthenticationInvokerRequestExecutor” bean simply tells the “HttpInvokerProxyFactoryBean” to use a special InvokerRequestExecutor which is capable of logging into the service. The BasicAuthenticationInvokerRequestExecutor basically comes from a Spring Forum, and is shown in its modified form next:
package uk.co.maxant.spring.remoting; import java.io.ByteArrayOutputStream; import java.io.IOException; import java.net.URI; import java.net.URISyntaxException; import java.util.ArrayList; import java.util.List; import org.apache.commons.httpclient.Credentials; import org.apache.commons.httpclient.HttpClient; import org.apache.commons.httpclient.UsernamePasswordCredentials; import org.apache.commons.httpclient.auth.AuthPolicy; import org.springframework.remoting.httpinvoker.CommonsHttpInvokerRequestExecutor; import org.springframework.remoting.httpinvoker.HttpInvokerClientConfiguration; import org.springframework.remoting.support.RemoteInvocationResult; public class BasicAuthenticationInvokerRequestExecutor extends CommonsHttpInvokerRequestExecutor { private String username; private String password; private boolean httpClientStateSet = false; public void setUsername(String username) { this.username = username; this.httpClientStateSet = false; } public synchronized void setPassword(String password) { this.password = password; this.httpClientStateSet = false; } protected RemoteInvocationResult doExecuteRequest( final HttpInvokerClientConfiguration config, final ByteArrayOutputStream baos) throws IOException, ClassNotFoundException { synchronized (this) { if (!this.httpClientStateSet) { final HttpClient client = getHttpClient(); final URI uri; try { uri = new URI(config.getServiceUrl()); } catch (URISyntaxException e) { final IOException ioe = new IOException(); ioe.initCause(e); throw ioe; } if (username != null && password != null) { Credentials defaultcreds = new UsernamePasswordCredentials( username, password); //the URI created above, could be used to fill //in the port and host, but its not actually required. client.getState().setCredentials(null, null, defaultcreds); //This is to make HttpClient pick the Basic authentication //scheme over NTLM & Digest List<String> authPrefs = new ArrayList<String>(3); authPrefs.add(AuthPolicy.BASIC); authPrefs.add(AuthPolicy.NTLM); authPrefs.add(AuthPolicy.DIGEST); client.getParams().setParameter( AuthPolicy.AUTH_SCHEME_PRIORITY, authPrefs); client.getParams().setAuthenticationPreemptive(true); } else { throw new NullPointerException( “Username and Password cannot be null”); } this.httpClientStateSet = true; } } return super.doExecuteRequest(config, baos); } }
This class uses the Apache Commons HttpClient to use basic authentication when it logs into the web application when it calls the remote service.

Finally, the code which calls the remote service:
package uk.co.maxant.test.spring.remoting.client; import org.springframework.context.ApplicationContext; import org.springframework.context.support.ClassPathXmlApplicationContext; import uk.co.maxant.spring.remoting.BasicAuthenticationInvokerRequestExecutor; import uk.co.maxant.test.spring.service.TestService; public class RemoteClient { public static void main(String[] args) throws Throwable { ApplicationContext context = new ClassPathXmlApplicationContext(“applicationContext.xml”); Object obj = context.getBean(“basicAuthenticationInvokerRequestExecutor”); BasicAuthenticationInvokerRequestExecutor executor = (BasicAuthenticationInvokerRequestExecutor)obj; executor.setUsername(“admin2”); executor.setPassword(“admin2”); obj = context.getBean(“testService”); TestService service = (TestService)obj; String s = null; int NUM_CALLS = 100; long start = System.nanoTime(); for(int i = 0; i < NUM_CALLS; i++){ s = service.sayHello(“Remote client”); } System.out.println(“Remote service says: ” + s + ” (called on average in ” + ((System.nanoTime()-start)/1000000.0/NUM_CALLS) + “ms).”); } } On thing missing in the above description, is that the client needs a reference to the service interface. In this example, built in Eclipse 3.4, the client project simply has a reference to the web application project containing the service interface. In reality you would want to have this interface in a client library which both the web application and the client can refer to.

Now everything is in place to call services on a remote server from a client, securely, and independently of application server Client Container. I chose to use Spring HTTP Remoting with standard Java serialisation (as opposed to Hessian or Burlap, which have their own problems due to restrictive serialisation), which locks the client and server to compatible Java versions. However, Java serialisation has not changed much in a while and I have successfully tested a client running in Sun Java 1.3, calling a Sun Java 1.6 server!

That is the end of this article, I hope it works for you, and gives you an insight into how to securely call services in a Java EE application server without the need to use the client container. Good Luck!