Align TomEE and DeltaSpike ciphering configuration

When you develop an application relying on a container for its awesome features you often hit the fact you use several code bases to do the same thing. In the context of this post it will be the ciphering of the passwords in the configuration:

• TomEE does it using PasswordCipher API
• DeltaSpike does it using ConfigFilter API

So finally you end up having to maintain two ciphering solutions which makes hard to production teams to maintain the configuration without developpers.

TomEE, @WebServiceRef and configuration

TomEE+ integrates JAX-WS thanks to CXF implementation. It allows you
to develop Pojo or EJB webservices but TomEE takes care to keep all CXF features.

This means you can use openejb-jar.xml to configure your webservice.

As a quick reminder the configuration (openejb-jar.xml) looks like the following one for an EJB:

<?xml version="1.0" encoding="UTF-8"?>
<openejb-jar xmlns="http://www.openejb.org/openejb-jar/1.1">
  <ejb-deployment ejb-name="CalculatorBean"> <!-- configure the bean, values are in resources.xml -->
    <properties>
      cxf.jaxws.in-interceptors = serviceIdInResourcesXml,com.foo.FullyQualifiedInterceptor
      cxf.jaxws.out-interceptors = abc
      cxf.jaxws.in-fault-interceptors = def
      cxf.jaxws.out-fault-interceptors = hgi
      cxf.jaxws.features = jkl
      cxf.jaxws.debug = true
    </properties>
  </ejb-deployment>
</openejb-jar>

For a Pojo webservice it is the same but using pojo-deployment instead of ejb-deployment.

TomEE also has (historically) some specific integration with wss4j but with
the previous configuration it is pretty useless now. Only thing to know
about wss4j is openejb provides WSS4JInInterceptorFactory factory
to ease initialization of WSS4JInInterceptor interceptor (because it has
two constructors with a single parameter and it can be ambiguous in some cases).

Finally to configure wss4j you can do a resources.xml like:

<?xml version="1.0"?>
<resources>
  <Service id="wss4jin" class-name="org.apache.openejb.server.cxf.config.WSS4JInInterceptorFactory" factory-name="create">
    passwordType = PasswordDigest
    action = UsernameToken
    passwordCallbackClass = com.foo.MyCallbackHandler
  </Service>
</resources>

And an openejb-jar.xml like:

<?xml version="1.0" encoding="UTF-8"?>
<openejb-jar xmlns="http://www.openejb.org/openejb-jar/1.1">
  <ejb-deployment ejb-name="CalculatorBean"> <!-- configure the bean, values are in resources.xml -->
    <properties>
      cxf.jaxws.in-interceptors = org.apache.cxf.binding.soap.saaj.SAAJInInterceptor,wss4jin,org.apache.openejb.server.cxf.WSSPassThroughInterceptor
    </properties>
  </ejb-deployment>
</openejb-jar>

This is great but it has a pitfall: it is only for the server side!

This is the reason it was recently enhanced (will be available in next 1.7.2 and 2.x versions) to
support almost the same configuration for clients.

In JavaEE clients are done thanks to @WebServiceRef. TomEE already optimizes them
using local invocation when the service is deployed int the same instance and doesn’t need
remote invocation (ie it has no webservice handler) but if you needed to customize
the client for remote case (ading security, adding logging, …) you needed
to cast it thanks to CXF APIs and programmtically customize the port.

When @WebServiceRef is used to get injected a port (ie a real client) you can now simply
configure CXF client like on server side.

However client doesn’t match pojo-deployment or ejb-deployment. That is why it uses
application.properties (in WEB-INF folder). Syntax is exactly the same but in properties
format. Prefix is “cxf.jaxws.client.” or “cxf.jaxws.client.{namespace}PortName”.
Take care first one is global (ie shared for all clients) and second one is specific to a port.

Like explaining such a configuration would not be that efficient here a sample:

cxf.jaxws.client.{http://cxf.server.openejb.apache.org/}MyWebservicePort.out-interceptors = wss4jout

wss4jout = new://Service?class-name=org.apache.cxf.ws.security.wss4j.WSS4JOutInterceptor&constructor=properties
wss4jout.properties = $outProperties

# using a pass-through class to configure more easily properties
outProperties = new://Service?class-name=org.apache.openejb.config.sys.MapFactory
outProperties.action = UsernameToken
outProperties.passwordType = PasswordDigest
outProperties.passwordCallbackClass = com.foo.MyClientCallbackHandler

Bonus: a Service (or a subclass of Service) can be injected as well. Customization doesn’t go as far as for the port but you
can set WSFeatures using the key: cxf.jaxws.client.xxx.wsFeatures and the value has to be a list of id or fully qualified name
of WSFeatures.

On recent version using resources.xml for Service should be possible as well, mainly a taste
question :).

JSon for configuration: Apache Johnzon made another step with comments

Using JSon for a configuration file is very tempting but there is a big drawback: you can’t comment anything with a strict JSon parser.

This is something which is blocking for a configuration IMO because you often need to explain why you configured something in the way it is.