Your views on Web Services Security

This is question fot RMH.
I often hear people say that Security is a key obstacle in wide spread adoption of Web Services.
It was not until Netscape introduced SSL and HTTPS that commerce on the Web flourished. And despite the criticism of PKI and HTTPS, these technologies solve the problem of Web security in most people's mind.
SSL and other Transport oriented security mechanisms, such as HTTP-Basic and HTTP-Digest authentication, though applicable to Web Services (atleast those involving SOAP over HTTP and not using content-aware routers), are not seen as ultimate solution to the Web Services Security problem. In the beginning, there was some talk of using message level security such as S/MIME, but I don't hear much about that now.
A lot of people expect WS-Security, a specification originally authored by IBM, Microsoft and VeriSign, and now being standardized at OASIS, to solve the issue of Web Services Security once and for all.
That brings me to my questions:
1. Do you think that WS-Security is the right answer to Web Services Security problem? If yes, why? If no, why? What are different forces at work here?
2. What would be a good way to incorporate WS-Security in J2EE Web Services? Are the JAX-RPC handlers the right answer? or should this be pushed down to the J2EE container?
Best Regards,
Pankaj Kumar.

Hi Pankaj,
Thanks for the question. I won't pretend to be an security expert when it comes to Web services, but I belive that WS-Security, while complex, provides a decent foundation for Web services security.
In the short run I think people will use SSL with Basic AUTH if they need security for the wire. I think a bigger concern over the long run will be fraudulent use of Web services. I talk a little bit about this on an old <a href="http://www.oreillynet.com/pub/wlg/1515">blog</a>

When it comes to impl WS-Security on J2EE, I think the best choice will probably come down to a combination of JAX-RPC Handlers and Servelt Filters, assuming you are using JAX-RPC Service Endpoints rather than EJB Endponts - EJB doesn't have filters.