Earlier this year, I gave a talk with on Breaking Web Services with Brian Chess at RSA. We pointed out that adding security into Web services is an exercise left to the implementer, the standards bodies and vendors give you some primitives, but it is still up to you to figure out all of the items on the Web services security checklist should work together in a cohesive system. Needless to say, there are many ways to shoot yourself in the foot.
So during our talk, someone from Oracle stands up and says, "hey, you guys are making this stuff sound hard. Its not hard we support WS-Security..." etc. Again, the whole point of our presentation was *not* that there are not very interesting general purpose security capabilities in Web services, our point was that you need to figure out the architecture yourself, and then bend the tools to your will. Oh, and deliver on time.
So imagine my surprise, when I read this article "Digitally Signing and Verifying Messages in Web Services" which talks about using Oracle's WSM tools to sign Web service messages and verify signatures in Web service messages, but only addresses integrity - absolutely nowt on authenticity! Integrity is important, but there are lots of times when it is not enough. Many times your service needs to be concerned with replay attacks, authentication policies and so on. To deal with those things, we would typically add policies and capabilities for timestamps, nonces and other primitives into the signature block, but the article is silent on those things. (Rad Mark O'Neill's post on this as well)
Its not about _can_ the standards do something or other, I mean given the right resources the standards can put a monkey on the moon, its about what use cases have they engineered in and what is supported in the tools today. I firmly believe SAML has such great adoption across the industry because they have a use case centric view and so gave the vendors something to engineer and optimize for. I think we'll still get there in WS-Security and other areas as well, but the use cases are not built into the spec (as with SAML) and so its taking longer.
One of our points in the talk was - we want you vendors to do your job better and instead of shipping a box Legos, ship a Lego gas station, a Lego airport, and so on. Connect some dots for your customers.
What I see in training on this topic, is sort of the following - 1) Do I need Web service security? 2) Oh ok, well can I get by with SSL? 3) Oh wait that doesn't actually protect my assets, can I just use WS-Security? 4) Oh wait, WS-Security isn't just a checkbox for security, I need to figure out timestamps, nonces, signatures, encryption policies and so on. And finally 5) How do I accomplish this?
Once we get to step 5 then the real work can begin. Its not easy to get a lot of developers through all of this, and again this is before the real work begins. Even once the lead developers and architects figure this out, there is still the little matter of transitioning it to the rest of the team.
I remember I was working with an enterprise architect several years ago, and he bought a Web service XML gateway like Vordel to add WS-Security support into his Web services apps, but he didn't even buy it as a runtime tool, he bought it as Security API, the runtime enforcement in his opinion was a bonus! He said in effect, well I know I need to do this, but I can't expose all these security primitives directly to my developers.
So yeah, I wish it was easier, but in my experience its not right now. Its not about raw capabilities its about use case realization. I think learning from what has worked well is the way to go. SAML's use case centric approach is one that has.
Comments