It seems web service security is not the easiest thing to get right the first time as some things in life (at least for me :D). I found this the hard way by trying to secure a service web service deployed in Axis2 with Rampart. Idea was simple. To make a service require a time stamped message from client vice versa. So I added the required parameters for both services.xml at the service side and the axis2.xml of the client side and added and enagaged Rampart module at both sides. Naturally I now expected to things work and see time stamped message flying in and out from my client through the Apache TCPMon setup to intercept the message flow. But I was expecting things to happen bit too early.
Troubles started with Axis2 server installation spitting a ClassNotFoundException for some org.apache.rampart.xxx.RampartXXX . After playing with the installation and Rampart module for some time I found out that there is a set of jars within Rampart module download which I should add to Axis2 installation lib to get over this obstacle. I don’t remember finding any documentation about Rampart stating this fact. Of course I may not have been looking hard enough or looking in correct locations.
But anyway straight ahead I hit another exception. This time it was a depressing org.apache.axis2.deployment.DeploymentException: javax/jms/BytesMessage. This was promising to be a show stopper. Luckily this same issue had come in the Axis2 list and I found that this was due to a version mismatch. I had been using Rampart 1.4 module with Axis2 1.5.1 version. Solution was clear. To use recently released Rampart 1.5 version. Magically that error was no more.
Next up in the “exception line up” was java.lang.ClassNotFoundException: org.apache.axis2.transport.tcp.TCPTransportSender. Apparently this was due to some related jar missing from Axis2 distribution. As per some discussion on Axis2 list I tried commenting out in server axis2.xml to trivially to make things work. I got over the next ClassNotFoundException by commenting out the transportReceiver for TCP following the same logic.
I ran the service client once again not even half expecting things to work. All of a sudden… You can guess my jubilation. Yeah finally my little time stamped SOAP has seen the light of the day. Though a painful experience I learnt that perseverance pays in security business.
I came across some other types of exceptions during my endeavour which I think can be useful to know for some other person venturing to this area.
org.apache.axis2.AxisFault: Must Understand check failed for header http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd : Security
This can occur due to two reasons as I observed. Firstly if the rampart module has not been correctly engaged to the service this error can occur when invoked. Secondly if either both endpoints are not correctly configured so that one end is not providing for what other end is expecting this error can occur. Say for example the service is configured to accept only time stamped messages then if a client sends it a non time stamped message then this error will occur. The same way if the client is expecting a time stamped message on return and if the service is not providing that this exception will be raised at the client side.