In-Depth

Q&A: Web services security

• By Jack Vaughan
• December 1, 2003

Toufic Boubez [shown here at left] has a stellar record in Web services. At IBM, he co-authored UDDI. Later, he founded Layer 7 Technologies which recently released SecureSpan to promote Web services security and integration policy creation. Jack Vaughan met with Boubez over iced tea in the friendly confines of Boston's Seaport District.

Q: Do people who get XSLT and WSDL tools off the Web, and start using and studying XML, then look to you for tools in the realm of security?

A: The interesting thing is that every time I talk to customers these days, I'm very surprised by the level of technical savviness that these people have. The people I am talking about understand WSDL and what the issues are. They actually build their own and use a variety of toolkits. It's squarely in both camps right now. I haven't seen any camp really winning so far, but there's a lot of .NET and Java-based Web services out there.

Q: One hope in the early days was to connect .NET and Java. Do you see that happening?

A: That's starting to happen a little bit more. I'm hoping that something like the WS-I guidelines will help there in terms of interoperability. It was tough going in the early days, and still is to a certain extent; unfortunately, even within one platform you sometimes get interop problems.

Q: How important are RPCs in SOAP? Should one "stay away from RPCs"?

A: I tend to agree. Aside from talking about sound architectural principles and things like that, even when you get to the bits and bytes, if you look at the SOAP message itself there are lots of areas of what's called tight coupling that can be decoupled. One of them is this issue of RPC where if you change the low part of the API on the service level, on the server, now your client just broke. You have to go back and re-do your client one way or another. If there were a way to avoid it, I would avoid it. People should start thinking more along the lines of message-oriented Web services and asynchronous Web services where you just dump a document down the queue, somebody picks it up later on and it's a document.

Q: When I first heard about Web services, that's the only kind I imagined.

A: That's so funny, because when we first came out with Web services at IBM, in 1999 I think it was, before it was called Web services it was exactly that. It was an XML document being dumped down a queue, being picked up at the other side where it was interpreted correctly, processed and then the results were sent back. So you're absolutely right. The whole RPC thing came back later for a couple of reasons. One of them is that it's a lot easier to do RPC. The other one is that the toolkits that are out there today, if you look at them, most of them will give you the easy way to do things by using everything that's automated in the toolkit, and that gives you RPC.

Q: How do people find their mistakes today? Are there adequate test tools in this space?

A: Debugging Web services is still a bit of an issue, especially when they're distributed. But there are a couple of test tools. Stuff is starting to happen because there's a need for it. It's kind of a chicken and an egg [situation].

Q: When do people realize they need security?

A: It depends on the people, the company and the kind of business it does and, fortunately or unfortunately, it depends on the kind of people that are the chief architects, architects or CTOs. It depends on what their background and experience is. If they have the 'been-there-done-that' kind of experience, they think of security as they are architecting the product or services. What they end up doing even though they're architecting with security from the beginning - and I'd say this happens in maybe 90% of the cases I've seen - is that they build the pilot for the prototype either without security or with the security baked into it, so when it's time to investigate, experiment or try different things, they have to go back to the code base and meddle with security there, which is an issue. It ends up always being an issue for them.

Q: Layer 7 has announced SecureSpan Solution for coordinating security and policies for Web services. How much security-oriented handcoding is required in Web services today?

A: Currently, any Web services security is mostly hand-coded. The major Web services vendors, such as IBM, Microsoft, BEA, Sun, etc all offer Web services security tools, but these tools are geared towards programmers, not administrators. This poses many problems, not the least of which being the time, effort, cost and increased security risk inherent in non-reusable hand-coded security solutions. We believe that enterprise security, especially in Web services, should be an administrative task not a programming task. This is reiforced by all customer conversations that we've had.

Q: Can security actually be, as Web services are often described, "loosely coupled?"

A: This is actually the crux of the problem. Let's step back for a second and reconsider. "Web services" denotes a set of technologies that is supposed to allow you to attain the ideal of just-in-time integration through loosely coupled systems. But the current model in its current use breaks down when it comes to anything other than the simplest, most straight-forward "getQuote" type of toy examples. There are many areas of tight coupling in the SOAP message alone. Starting with something as simple as the SOAP address of the web service, to all the various required headers for security or otherwise, and much more importantly, at the API level, where the semantics of the API need to be completely specified beforehand at design time. But the model breaks down in an especially serious manner where security is concerned.

For one thing, WSDL has no way of conveying security access mechanisms so that they can be automated. Even if it did, tools, as I mentioned before, are mainly geared towards design time developer tasks. In typical Web services scenarios, security mechanisms such as authentication, authorization, credential presentation, encryption, or digital signature requirements are hard coded into the Web service. The equivalent mechanisms must then be hard coded into the client applications that invoke this Web service. This results in a system where the requesting client application is tightly coupled to the implementation of the service, and breaks down if any of these terms need to be changed. But, to get back to the question, there definitely is a mechanism to make Web services security loosely coupled. This is where the crucial concept of policy enters the picture. In order to provide flexibility to an otherwise brittle system, policy documents have to be created to decouple "invariants" from "environment variables". In this context, what I consider to be an invariant is the actual functionality of the service, tested and deployed, and not to be touched again until the business requirements change.

What I consider to be the variables are the policies (including security policies) around this service. Security policy enforcement points must be implemented as a layer in front of the deployed web services, so that the web service is decoupled from its security requirements. This practice is becoming more common, but in itself addresses only one side of the issue. A system cannot be "half" loosely coupled - it either is or isn't. What's needed to complete the solution is a new concept that we're proposing, the policy application point, at the client side. This is where the requester is also decoupled from the security policy requirements, in the same way that the policy enforcement point decoupled the web service itself. The policy application and enforcement points can exchange policy documents and coordinate at runtime to make the whole security mechanism truly loosely coupled. This in essence is one of the most important features of the SecureSpan Solution.

For more XML news, go to ADT XML Page.