WS-Security 1.0 has been around since the start of 2004 as a formal Oasis spec, so one could hope that now, two years later, using this stuff was much easier. Unfortunately, it doesn't appear to be so.

There are many fine toolkits now that implement support for WS-Security in several different SOAP stacks, like WSE for .NET and WSS4J with Axis for Java, and they work really nicely, overall, and make WS-Security more approachable by the average developer.

As an architect, I like WS-Security in the sense that it provides a standards-based solution to the difficulties of securing Web Services; I always recommend to my clients that they look first into using standards-based solutions whenever possible, particularly when there is something to be gained from it (in this case that would be thing like composability and interoperability). However, I will admit that sometimes I have second thoughts about using the WS-Security stuff.

My reasons, however, are not entirely technical. The thing is, we've had significant problems with some of the clients I've worked with on using WS-Security to secure their services, but not because of WS-Security itself. The problem is the lack of information and penetration. Unfortunately, while here in Colombia some things are actually very advanced, the whole Software Development world is, in general, somewhat behind the technology adoption lifecycle. This means that very few people have experience working with things like WS-Security.

In turn, that means that while we work very successfully with our clients on creating WS-Security-based services, they usually have a very though time getting other providers and customers of them to consume the services. Sometimes this is just because the developers themselves have no clue as to how to approach it: they barely know what SOAP is,  though they can use basic tools to consume them. They usually don't know WS-Security at all, or what it implies (a UsernameToken? what is that?). Thus, they don't even know what tools to use.

A second problem is that sometimes, these people are using tools that are just not to the task. For example, a client of a client of ours from another country was still using .NET v1.0, which, in typical Microsoft fashion, WSE 2.0 does not support. Hence, no WS-Security support at all. They had to jump through hoops to support this. Other times, they are using older Java SOAP Toolkits that don't support this, either, so you have to get them to move to more mature implementations, which the usual delay this might imply.

And sometimes, people just do right out weird things. For example, I once saw a certain association secure a Java-based Web Service in a way that really surprised me! They had an RPC/Encoded service that required HTTP Basic Authentication over SSL and that required mutual authentication underneath using X.509-Security tokens. Clunky at best.

These kind of things, coupled together with the fact that diagnostic and debugging authentication problems in WS-Security toolkits isn't as easy as it should, usually conspire to make the use of a standards-oriented solution more costly during development, but I still believe it is an investment worth making in the mid-term.

I'd love to hear what others have experienced regarding WS-Security adoption.