Signing and Validating Soap requests with Mule ESB

Some months ago I have been busy implementing a web-service-proxy by using the Mule ESB CE. Although it took some work to get it up setup nicely it is working well now for quite some time. In this post I will show you the result. Lets start with the configuration of the incoming request that is signed and has to validated. By the way, I know there is also the webservice-proxy-pattern in Mule but I couldn’t use this in combination with the signing/ validating which I needed to do. So here is the flow which validates the incoming SOAP request:

<flow name="order-status-update">
        <https:inbound-endpoint address="${my.incoming.url}" connector-ref="httpsConnector">
            <cxf:proxy-service>
                <cxf:inInterceptors>
                    <spring:bean class="org.apache.cxf.interceptor.LoggingInInterceptor" />
                    <spring:bean class="org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor">
                        <spring:constructor-arg>
                            <spring:map>
                                <spring:entry key="action" value="Signature" />
                                <spring:entry key="signaturePropFile" value="ws-validate-security.properties" />
                            </spring:map>
                        </spring:constructor-arg>
                    </spring:bean>
                </cxf:inInterceptors>
            </cxf:proxy-service>
        </https:inbound-endpoint>
        <https:outbound-endpoint address="${my.internal.url}" connector-ref="httpsConnector">
            <cxf:proxy-client />
        </https:outbound-endpoint>
    </flow>

Note: please note that the ‘${}’ values are properties read from a property file as described in this article.

As you can see I have defined a CXF proxy with two interceptors: one for logging and one to perform security actions by using the Apache WSS4J library. I supply two parameters to the WSS4JInInterceptor:

• ‘action’: describes which action has to be performed by the Interceptor. Possible values are ‘Signature’, ‘Timestamp’, ‘Encrypt’ and more.
• ‘signaturePropFile’: parameter refers to the property file to be used by the interceptor.

The contents of the ‘ws-validate-security.properties’ which is placed on the Mule classpath reads the following:

org.apache.ws.security.crypto.provider=org.apache.ws.security.components.crypto.Merlin
org.apache.ws.security.crypto.merlin.keystore.type=JKS
org.apache.ws.security.crypto.merlin.file=/usr/local/keystores/myKeystore.jks
org.apache.ws.security.crypto.merlin.keystore.password=myPassword

For more detailed description of these properties and the used technology see this article.
But this is it to have this part configured. I used Mule CE 3.2 in this case. The mule config uses the following namespaces:

<mule xmlns="http://www.mulesoft.org/schema/mule/core"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xmlns:cxf="http://www.mulesoft.org/schema/mule/cxf"
      xmlns:spring="http://www.springframework.org/schema/beans"
      xmlns:https="http://www.mulesoft.org/schema/mule/https"
      xsi:schemaLocation="
        http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/3.2/mule.xsd
        http://www.mulesoft.org/schema/mule/cxf http://www.mulesoft.org/schema/mule/cxf/3.2/mule-cxf.xsd
        http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
        http://www.mulesoft.org/schema/mule/https http://www.mulesoft.org/schema/mule/https/3.2/mule-https.xsd">

For completeness the used dependencies in the ‘pom.xml’ are the following:

<dependency>
  <groupId>org.mule</groupId>
  <artifactId>mule-core</artifactId>
  <version>3.2.1</version>
  <scope>provided</scope>
</dependency>
<dependency>
  <groupId>org.mule.modules</groupId>
  <artifactId>mule-module-spring-config</artifactId>
  <version>3.2.1</version>
  <scope>provided</scope>
</dependency> 
<dependency>
  <groupId>org.mule.transports</groupId>
  <artifactId>mule-transport-http</artifactId>
  <version>3.2.1</version>
  <scope>provided</scope>
</dependency>
<dependency>
  <groupId>org.mule.modules</groupId>
  <artifactId>mule-module-cxf</artifactId>
  <version>3.2.1</version>
  <scope>provided</scope>
</dependency>

And here is the configuration for signing outgoing requests:

<flow name="place-order">
  <https:inbound-endpoint address="${my.internal.url}" connector-ref="httpsConnector" responseTimeout="0">
    <cxf:proxy-service enableMuleSoapHeaders="false" payload="envelope" />
  </https:inbound-endpoint>
  <https:outbound-endpoint address="${my.outgoing.url}" connector-ref="httpsConnector" responseTimeout="0" >
    <cxf:proxy-client payload="envelope">
      <cxf:outInterceptors>
        <spring:bean class="org.apache.cxf.ws.security.wss4j.WSS4JOutInterceptor">
          <spring:constructor-arg>
            <spring:map>
              <spring:entry key="action" value="Signature" />
              <spring:entry key="user" value="${signature.user}" />
              <spring:entry key="signaturePropFile" value="ws-sign-security.properties" />
              <spring:entry key="passwordCallbackClass" value="net.pascalalma.MyKeystorePasswordCallback"/>
              <spring:entry key="signatureKeyIdentifier" value="DirectReference" />
            </spring:map>
          </spring:constructor-arg>
        </spring:bean>
        <spring:bean class="org.apache.cxf.interceptor.LoggingOutInterceptor" />
      </cxf:outInterceptors>
    </cxf:proxy-client>
  </https:outbound-endpoint> 
</flow>

The important Interceptor here is of course the WSS4JOutInterceptor. The properties configured here are:

• ‘action’: describes which action has to be performed by the Interceptor
• ‘user’: The certificate alias in the signature crypto config to sign the message with. The password is retrieved from the callback handler.
• ‘signaturePropFile’: Defines the file name that contains a Properties with the desired settings in it.
• ‘passwordCallbackClass’: The reference to the callback handler for retrieving passwords for private keys in the signature and encryption crypto configurations.
• ‘signatureKeyIdentifier’: Signature key attachment method. I want to put the token directly in the header and not use a reference.

The ‘signaturePropFile’ contains the following info:

org.apache.ws.security.crypto.provider=org.apache.ws.security.components.crypto.Merlin
org.apache.ws.security.crypto.merlin.keystore.type=JKS
org.apache.ws.security.crypto.merlin.file=/usr/local/keystores/myKeystore.jks
org.apache.ws.security.crypto.merlin.keystore.password=myPassword

As you can see I added the password which is used to open the keyStore here in plain text. Of course this is not the way to do it in a production system but for development it is quite convenient. I use the MyKeystorePasswordCallback to get this password as is shown in the following implementation of this class:

package net.pascalalma;

import java.io.IOException;
import java.util.ResourceBundle;

import javax.security.auth.callback.Callback;
import javax.security.auth.callback.CallbackHandler;
import javax.security.auth.callback.UnsupportedCallbackException;

import org.apache.ws.security.WSPasswordCallback;
/**
 *
 * @author Pascal Alma
 */
public class MyKeystorePasswordCallback implements CallbackHandler {

    private static final String BUNDLE_LOCATION = "ws-sign-security";
    private static final String PASSWORD_PROPERTY_NAME = "org.apache.ws.security.crypto.merlin.keystore.password";	

    private static String password;
    static {
        final ResourceBundle bundle = ResourceBundle.getBundle(BUNDLE_LOCATION);
        password = bundle.getString(PASSWORD_PROPERTY_NAME);
    }	

    public void handle(Callback[] callbacks) throws IOException, UnsupportedCallbackException {
        WSPasswordCallback pc = (WSPasswordCallback) callbacks[0];

        // set the password for our message.
        pc.setPassword(password);
    }
}

This concludes the example of a complete configuration for signing and validating SOAP requests with the Mule ESB. Although it is not rocket science it took quite some time to get the complete configuration together and working. And there is still room for improvement, mainly for the error handling but I leave that for another time 🙂

Advertisement