WS-Policy and My Dog Lily

This is my dog, Lily. Besides being and adorable puppie-wuppie, she was born blind. Yet here is a picture of her swimming in a lake. I wish I had video of her...she will swim out and fetch the ball. I'm not kidding. She is amazing. So how does she do it? Well, as it turns out "sighted" dogs have lousy sight. Dogs actually have a really good sense of smell, and hearing, and Lily uses some combination of these find the ball.

WS-Policy, despite what people make think, does not necessarily make interoperability of web-services any easier. Practical interoperability is actually achieved at the WS-Security level - through the exchange of messages. WS-Policy as a standard does not prescribe what the corresponding message looks like. It just says "this message is going to be encrypted with Basic 256". We can all agree that there are lots of ways that SOAP message could look...WS-Security gives us a lot of help here, but as you wade through the various pieces of WS-Security specification, and get into things like Derived and Encrypted Keys, there are a lot of inferences that are left to be made between the WS-Policy and the SOAP message.

I'm not on a crusade against WS-Policy, but I've run into a number of customers in the past few weeks that have gotten hung up on WS-Policy and in particular OSB's inability in the current release to consume WS-Policy on a WSDL. This is just a "Blind Dog"...OSB has rich WS-Security capabilities and can work with many of those end points even if it doesn't understand the assertions. Why? Because OSB supports WS-Security 1.0, SAML 1.1, Transport Level Security with SSL...and these capabilities are broadly interoperable with a number of Web Service vendors and implementations.

The key is that OSB, and WLS and OWSM for that matter, all have the ability to define a policy to be used on the client. It does not have to come from the WS-Policy attached to the WSDL. The "trick" is that you may have to simply remove the offending WS-Policy statements from the WSDL - and save it locally - to get client side stubs to get design time tooling - OSB pipeline or JAX-WS/RPC client stubs.

This does require some understanding of what the server's WS-Policy is trying to say...that is what does it expect....version of WS-Security, Is it signed, Is it encrypted, what tokens are included? Fortunately, WLS, OSB and OWSM all include pre-built client side policies that include some best practices and common scenarios, so that in most cases, you won't have to start from scratch, or modify the client policies at all. You just need to know which one to pick...pretty straight forward, assuming that you know something about the WS-Policy and what it means. If your expectation is that WS-Policy will just magically make security happen, then I think that we as an industry are a long way away from that Nirvana.

I work with many customers that have WS-Policy implementations that both "sides" understand, but still the messages don't work. There is no substitute for testing....that is vendor-to-vendor industry interoperability testing. Vendors continue to invest in this, but in the mean time, if you're going to use WS-Policy you'll need to understand how it works at some level. Remember, SSL or some other transport level security is always a reasonable choice. It meets many SOA security use cases.