Web services represent a whole new model for integrating applications, which means you have to think in a whole new way about security.
Web services refers to the use of standards such as XML, UDDI and SOAP to describe (XML), find (UDDI) and transport data (SOAP) among applications and business partners. The aim is to make it far easier than before to link applications over the Web, giving users and business partners access to the data -- and only the data -- they should see. But clear standards for securing Web services are at least a year off, delaying the widespread use of such services outside corporate firewalls.
Unlike current application-to-application integration, which relies on security mechanisms at each application or at each network, Web services will expose only selected application functionality, or "services" to users or other applications. If a user has read-only access to data, for example, the application should expose only the "view" and "print" services associated with that data, but not the "update" function. When these "services" are deployed over the Web, authentication and authorization credentials will need to follow a query (or the response to that query) across the traditional boundaries of applications, networks and organizations.
For those of you with networking backgrounds, think of it like this: Current security protocols, such as SSL (Secure Sockets Layer) work like the circuit-switched phone network, where the identity of the user and the details of what they can access last only as long as the connection does. Web services security will function more like the Internet, where multiple data packets share the same connection and carry their own descriptions of what they are and where they belong. When Web services become commonplace, authentication, authorization and even encryption data will tag along with XML-based documents as they traverse the Web.
So how do we get from here to there? In several steps, with the more advanced security coming with the finalization of key Web services security standards sometime in the latter half of next year. Let's take it chronologically.
For the next six months, at least, many customers will keep Web services within the firewall because they fear a world where multiple customers, suppliers and other business partners can link to your systems willy-nilly. (If you authenticate one user at your business partner as a legitimate user, have you then opened the door to anyone that business partner has ever authenticated?)
Except for the biggest, richest customers (who need and can afford today's Web services security products), IT managers will protect Web services with well-established Web-based security tools such as SSL and S-HTTP. They'll also be looking for firewalls with enough intelligence to examine each SOAP message and decide which to let through based on their content, rather than controlling access based on the origin of the message, the type of message, or the server, port or service it is trying to access.
Around the middle of next year, we'll start to see the shift to more of the "packet-switched" model where security information follows the document, with the firming up of standards such as the XML Key Management Specification (XKMS), which will cover the registration and distribution of XML-based public keys to encrypt and decrypt documents. Other emerging Web services standards include the XML Encryption standard, which will govern the encryption and decryption of digital content such as XML documents, and the XML Digital Signature Standard (XML-DSig), which will define how to digitally sign an XML document.
While the Web's governing bodies consider these specifications, vendors are figuring out which to support and exactly how to implement them. Uncertainty is the watchword for now. For example, the Organization for the Advancement of Structured Information Standards (OASIS) is developing SAML (Security Assertion Markup Language), designed to allow users to maintain their authentication and entitlement credentials over multiple Web sites. But citing slow progress on the standard and doubts over which vendors will support it, Gartner Inc. Analyst John Pescatore is pessimistic about SAML's chances to ensure interoperability among various access control systems. In fact, he estimates it will be the second half of 2003 before you can count on various vendors' implementations of Web security standards to work together.
Microsoft, IBM and VeriSign, for example, have teamed up to create WS-Security, a security language for Web services that will describe enhancements to SOAP messaging covering credential exchange, message integrity and message confidentiality. WS-Security is designed as a "building block" for future security and encryption tools and will support other key standards such as XML-DSig, the vendors say.
IBM is also positioning management tools from its Tivoli Systems Inc. unit, including Access Manager (formerly Policy Director,) Identity Director and Risk Manager, as Web services security tools. Microsoft Corp.'s .NET framework for Web services now supports the XML-DSig (XML Digital Signature Standard). It is also pushing its Passport authentication and identity service to provide access and single sign-on capabilities across business partners.
Sun Microsystems Inc. is backing a competing, multivendor service called the Liberty Alliance. It also recently shipped its Sun ONE Platform for Network Identity, a combination of hardware, software and services to manage the authorization and authentication of employees, customers and business partners.
Application platform vendor BEA Systems Inc. says its WebLogic 7.0 platform can be used to set policy-based Web services security policies and to provide features such as single sign-on across multiple applications. Some customers will also use portal-based access management tools such as Netegrity Inc.'s SiteMinder as a bridge to secure Web services.
Sound confusing? It is. What should you do? First, insist on strong support for Web services security standards from your server, access management, security and portal vendors. Second, keep an eye out for the powerful trade groups or consortia that will determine which of the various Web services security standards will matter most with your trading partners, so you can focus your efforts on those standards. And third, weigh the business risk carefully before deploying Web services outside the firewall. Web services themselves are uncharted territory, and keeping them secure will be pioneer's work for some time to come.About the author
Robert L. Scheier is a former technology editor at Computerworld, who writes frequently about security from Boylston, Mass. He can be reached at email@example.com.
Share your thoughts on this Scheier's Security Product Roundup in our Letters to the Editors discussion forum.