“Authorization Failed” in DFS-based Service (D6)

The DFS SDK provides convenience Java classes for writing a consumer for a DFS-based web service. The consumer itself can also be a service. On the other hand, a consumer can also be written to use only the service WSDL without using any of the DFS SDK tools. If you are writing both a custom DFS-based service and its consumer using the SDK, things work out relatively smoother. Since the same set of tools are creating the consumer as well as the service, it can ensure that they are compatible in all aspects. If you decide to create the consumer using only the WSDL, then the onus is on you to make it work.

I created a custom DFS-based service staring with the sample AcmeCustomService. I also created a Java consumer using the SDK and it was able to interact with the service easily. Next, I generated a client stub (the plumbing for communicating with the service) based on the WSDL using AXIS2 tools. I wrote a simple client to invoke the service using the stub. I held my breath as I ran the client – only to get a SerializableException. Note that any server-side exception would show up as this exception on the client side. I added some logging and obtained "Authorization Failed" as the embedded message. Note that both the clients were talking to the same service deployment. A day’s worth of research didn’t yield anything concrete. Finally, I started browsing the generated code for the service.

In the file named xxWebService.java where xx was the name of my main service file, there was an annotation reading

@javax.jws.HandlerChain(file="authorized-service-handler-chain.xml")

I tried to locate this file but couldn’t find it in the project. Finally, I found this file in the service EAR file that was being packaged and deployed. Next to it I found a file named anonymous-service-handler-chain.xml. The difference between the content of these two files was a handler dealing with authorization. So, a web service authorization was taking place and the consumer code generated by the DFS SDK was taking care of it somewhere.

There were two options at this time – make the service anonymous or figure out the right way to authenticate the client. I had spent enough time trying to make this work so I decided to just make the service anonymous by altering the annotation to

@javax.jws.HandlerChain(file="anonymous-service-handler-chain.xml")

Then I repackaged the EAR and redeployed it. That was it! The AXIS2-based client worked perfectly. By the way, the DFS SDK-generated Java consumer also continued to work.

Authorizing the consumer will be a battle for another day.