Feeds:
Posts
Comments

Archive for March, 2010

Do You Workrave???

Are you computoholic? Yep that’s a word I just made up. Not present in any dictionary. Do you tend to get up from the seat in front of your computer at the evening with the sudden revelation that you didn’t make it out of the room even two times within the day. Or are you suffering from eye problems due to excessive usage of computers. Then here is some thing that may worth checking out. Workrave is a small software which sits behind your back and says to you when to stop!. Yes you heard me. After certain interval it rings to you by giving visual indications that you should probably take some tea break or if not some exercises for your eye or your back. It plays you animations as well as how to do them. Pretty cool huh? The time intervals are configurable. So it is advisable to the set the break intervals that suites your work style. But don’t cheat and set the interval to 4 hrs. You know what I mean. In Ubuntu you can install it by

$sudo apt-get install workrave

It is cross platform. Google workrave you will get many references.

Advertisements

Read Full Post »

Tomcat Installation

The BASEDIR environment variable is not defined correctly.This environment variable is needed to run this program.

If you run in to the above while trying to run Tomcat make sure both $CATALINA_HOME and $JAVA_HOME are set properly. If it still doesn’t work try changing the permissions as following.

chmod +x ./setclasspath.sh
chmod +x ./startup.sh
chmod +x ./shutdown.sh

Read Full Post »

Continuing my adventure with Apache Rampart from my earlier article I decided to follow the DeveloperWorks article on WS-Security. Again I ran in to some issues when I tried using signatures within the messages. Here is a brief account of what happened this time.

First road block I encountered was the error shown below. The error was on the client side and was like this.

org.apache.axis2.AxisFault: CryptoFactory: Cannot load properties:crypto.properties

Client didn’t seem to know where to pick up the properties file describing trust store details. After fiddling with the file paths and failing, I tried the Axis2 list and luckily found a suggestion which helped out with my predicament. The solution was to add the properties file location to the client’s classpath. So with that obstacle out of the way the next break point to hit was this.

problemAction: anonOutInOp
[ERROR] The [action] cannot be processed at the receiver.
org.apache.axis2.AxisFault: The [action] cannot be processed at the receiver.

This time around it was the server side which was giving me troubles. After scavenging a little on the Internet for information I found this article which described the issue as not properly setting the SOAP action when setting up the client. I was guilty as charged. I had forgotten to set the SOAP action at my client. Thanks to that tip I pressed ahead again to come up with this.

org.apache.axis2.AxisFault: WSHandler: Signature: error during message processingorg.apache.ws.security.WSSecurityException: An unsupported token was provided (Problem with SKI information: Support for RSA key only)

Again luckily I found a suggestion on Axis2 list which helped me through. The error was due to the choice of the algorithm that I used generate the key store. Instead of the default DSA using RSA algorithm was the solution.

So after another bumpy ride I was finally able to get it working for signatures and luckily providing encryption capability was pretty much a smooth ride afterwards.

Read Full Post »

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.

PS.

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.

Read Full Post »