Pankaj Kumar's Weblog

Among all the chapters for J2EE Security book, the one on Web Services Security was most difficult to write. More so because I wanted the intended audience for the book, and hence this chapter, to be developers.

Writing about SSL based transport security was straight-forward. In fact, I had done some work in this direction long ago.

Most of the literature I came across talked about yet-to-come security standards. Even these standards were for securing XML and SOAP messages. I am talking specifically of WS Security. Even now, after the book is out in the market, the Oasis TC developing this specification has not completed its work. The Java API standards or even proprietary implementations were even harder to find.

So I ended up doing some heavy lifting and doing my own implementation based on VeriSign TSIK library that provides a WS Security implementation based on the initial WS-Security specification. I basically wrote JAX-RPC compliant handlers which made use of TSIK library to apply WS-Security based protection on SOAP messages and tested these on Apache Axis.

During this implementation, I did run into an interesting problem. The TSIK library worked on a W3C DOM document or Node, but what you got in a JAX-RPC handler was a SAAJ SOAPMessage object. Converting this into a W3C Document esentially mean't serialing the memory object and reading it back into a W3C DOM document. Once the WS Security related processing is over, this needs to be converted back into SOAPMessage. This is prohibitively expensive. (Note: SAAJ 1.2 has fixed this problem by requiring SOAPMessage to extend from org.w3c.dom.Node).

The good news is that you can read the complete chapter online as it happens to be the free sample chapter. The code is also available with an Open Source License.

VeriSign's sitefinder, which has angered the web-surfers (feed a misspelled or non-existent URL to your browser and you will know what I am talking about) and others, and for this reason, has been target of numerous lawsuits.

However, the problems faced by web-surfers appears to be a minor irritant compared to the grave problems being faced by applications that fetch information through URLs and Web Services, which rely on URLs for addressing. A lot of these have been coded on the assumption that a mis-spelled or non-existent host will be recognized by the returned error code but are now getting HTML documents, which they do not understand or expect. Steve has documented his travails with Apache Axis due to sitefinder.

Looks like we will all have to learn new ways of handling error ;-(

JavaRanch Book Review team has this nice review of J2EE Security for Servlets, EJBs and Web Services.

Here are excerpts:

"Security is like spinach - it's good for you but not too many people like it. Most security books bore me to tears with page after page of description accompanying three lines of code. This book is different."

"The explanations throughout the book are clear and easy to follow with plenty of code samples to demonstrate how to use the various APIs associated with security in Java programs. The best part of the book is the many code samples provided and the detailed descriptions accompanying these code samples."

Ovidiu Predescu, an old friend and now a Google employee, has written an excellent writeup on using ssh-agent on Windows XP for single authentication for all ssh-based logins. I got to follow his instructions and setup my Windows machines to use this!

A recent San Jose Mercury News article talked about some of the technologies/products for client-side solution to authentication at multiple websites: Windows password manager, roboform, iKey and so on.

Ofcourse, ssh-agent and these web sign-on products address different target markets, but attempt to solve the same problem.

Recently, I came across a variant of this problem -- we have a Java based client program that interacts with a number of different and independent Web Services. These Web Services could assign different usernames and passwords to the client, requiring the client to use something like a password manager.

The original W3C Note has SOAP as an acronym for Simple Object Access Protocol. Afterall, it was designed as an RPC protocol to invoke methods on objects.

The W3C Recommendation specifically states that SOAP 1.2 will not spell out the acronym. The reasoning was that object method invocation is only a secondary use, the primary being packaging XML documents that can be sent in any manner possible. Actually W3C started with XMLP (for XML Protocol) as the name for the protocol but accepted the term SOAP anyway.

Today, while browsing the Web, I came across this article that suggested SOAP for SOA Protocol. The same article also mentions that exposing object level access is against the SOA principles.

Works for me.