XML DEVELOPER
XML messaging security under the gun
Ed Tittel
03.13.2002
Rating: -3.67- (out of 5)
XML Developer Tip
XML messaging security under the gun
Ed Tittel
Leigh Dodds, author of the XML-Deviant column at xml.com puts forward some interesting summary and analysis from the XML developer community in a recent column entitled "In a Lather About Security." What he has to say is important and potentially serious enough to be worth a brief recap here, but those of you who are interested in more detail should not only read his story, but follow his links to the original source materials as well.
SOAP is the Simple Object Access Protocol, an XML-based technology designed to pass messages between applications across a network. RPC stands for Remote Procedure Call, and represents a set of programmatic interfaces to let local applications request and reply to network access and services "as if they were local." REST stands for Representational State Transfer, a Web oriented set of transaction services that defines its own mechanisms to model and handle networked transactions of all kinds.
As Dodd's article points out, there's a raging debate in the XML developer community right now that while SOAP-RPC is a powerful and all-too-usable technology to bolt applications and services together across a network, it's fraught with potential security issues that could be problematic in many, many scary ways. The real kicker is that using SOAP-RPC essentially hides all kinds of potentially classified or confidential information inside the standard Web communications protocol, HTTP. This not only makes it possible to slip SOAP-RPC traffic through corporate firewalls (normally deliberately open for Web traffic on port 80) but lets developers bypass or ignore security safeguards at the same time.
REST on the other hand takes a much more formal and explicit notion of transaction modeling into account when modeling and implementing networked
To continue reading for free, register below or login
To read more you must become a member of SearchSOA.com
communications. This makes it more straightforward and possible to build security concerns in from the ground up, and implies that this approach has a better chance of being secure. But like SOAP-RPC, while REST has the potential to offer enhanced security, it has no absolute requirements that security considerations be addressed in building and implementing transaction handling systems.
Dodds reports that Michael Brennan, of Allegis.com, says that issues likely to cause security problems in Web services are the same issues that cause such problems already (the following list is paraphrased from Brennan's original e-mail message). They include:
Ultimately, the real solution to these problems will come from training software architects and developers to "think security" from the very inception of their designs. It also means making security audits and testing part of standard software testing methodologies, and making sure that security issues are addressed when consumers go to vendors or service providers to purchase services, products, or information. Although these concerns address more than XML, they must become part and parcel of the way services are conceived, developed, and delivered. Because XML is key to development of future Web services, this debate must continue and be heeded within the XML community.
Have questions, comments, or feedback about this or other XML-related topics? Please e-mail me care of tips@searchwebservices.com. I'm always glad to hear from my readers.
About the Author
[IMAGE]Ed Tittel is a principal at LANWrights, Inc., a wholly owned subsidiary of LeapIt.com. LANWrights offers training, writing, and consulting services on Internet, networking, and Web topics (including XML and XHTML), plus various IT certifications (Microsoft, Sun/Java, and Prosoft/CIW).
For More Information
|
|
|
|
|
|
