The buzz accompanying Web services today no longer vibrates around system integration and XML interfaces, but around security – and the frantic, mish-mashed efforts to create security standards.
Web services are built with standard interfaces based on the Simple Object Access Protocol (SOAP) from the World Wide Web Consortium (W3C). But because SOAP is not secure at this point, Web services cannot achieve their mission of enabling business-to-business commerce and integration of business partners’ disparate platforms, network executives say.
Without security in the Web services framework/architecture, development of other Web services standards for e-commerce also will suffer, including those to support reliable and asynchronous messaging, business-process workflow and transactional integrity.
“Security is a rollout inhibitor today, absolutely,” says Mark Jones, vice-president of business development for the National Student Clearinghouse (NSC), a nonprofit organization in Herndon, Va., that provides university enrolment and degree verification services to lenders and businesses. NSC knows the issues firsthand, as it is on the verge of deploying two Web services to streamline the collection and dispersal of its data to potentially millions of partners.
Jones likens the challenge of establishing Web services for partner-to-partner trading to using public-key infrastructure and electronic data interchange. While standards-based partner-to-partner transactions are great conceptually, they’re difficult to implement. “Having just been through that for 10 or 15 years with [electronic data interchange], [I know] it is a very tough problem to solve,” he says. “No one has really perfected a way to do partner-to-partner trading yet. So we question the evolution of the standards and how well they will work.”
Jones isn’t alone. Recent surveys by Hurwitz Group and ZapThink show that security is the primary obstacle to adoption of corporate Web services.
Of course, security can be added to SOAP via extensions, and so a flurry of work to do so is in progress – spanning three standards bodies that have produced complementary but sometimes overlapping protocols. Extensions will standardize ways for systems to prove their identities, validate user authorization and access credentials, guarantee confidential transactions, and ensure integrity and nonrepudiation.
While waiting on standards ratification and vendor implementation of those extensions, many network executives are limiting Web services to intranet projects or improvising security when Web services traverse corporate boundaries. Such improvisation includes homegrown security, fitting established Internet standards or proprietary products onto projects, or contracting with third parties to supply security services. NSC sidestepped the standards maze by using software from Flamenco Networks to wrap authentication, authorization and management capabilities around its Web services, says Doug Falk, NSC CIO.
“We probably could have started with weaker encryption and relied on a model using HTTP-S and authenticating based on a user ID and password. That would have worked for a period of time until someone raised concerns over that model being too weak,” Falk says.
One firm that has decided to rely on HTTP-S is Data Jungle Inc., a Kanata, Ont.-based business intelligence (BI) software maker. Albert Scherbinsky, the firm’s senior development manager, says the security associated with regular Web transactions has matured to a high-enough level to make the choice not to involve SOAP in its Web services-related efforts much easier.
DataJungle makes a reporting solution that integrates with Cognos Inc.’s BI software. According to the firm’s president, Denes Bartakovich, although awareness of what Web services can do has risen significantly over the last year, most customers are just beginning to understand the concept’s potential.
“Customers are realizing the potential of integrating their own internal applications (with other ones) and the benefits of that,” said Bartakovich. “There is a lot of education (around Web services) going on.”
The rush is on
Meanwhile, XML standards bodies have been busy. The Internet Engineering Task Force (IETF), the Organization for the Advancement of Structured Information Standards (OASIS) and the W3C are working on or have completed no fewer than 13 security protocols usable with Web services. These include extensions for encryption, digital signatures, nonrepudiation and long-accepted standards such as Kerberos that are being folded into the Web services mold.
With so many cooks in the kitchen, the industry lacks a clear view of how individual Web services security specifications will be melded into an interoperable security framework.
To their credit, OASIS and W3C are comparing their efforts with the aim of clarifying the security work. “If any of these security specifications are going to work together, we have to work together,” says Karl Best, director of technical operations for OASIS.
The cooperation began with WS-Security, a specification proposed by IBM, Microsoft and VeriSign in April, 2002 and turned over to OASIS shortly thereafter. WS-Security, which lets Web services pass secure and signed SOAP messages, has at its core the W3C’s XML Encryption and XML Digital Signature and will add six other extensions for functions, such as expressing security policies, trust relationships, federation and authorization. Last August, OASIS and W3C sponsored a forum to compare and contrast work being done by both groups.
In addition to XML Digital Signature and XML Encryption, W3C is developing the XML Key Management Specification and a Web Service Architecture that includes a security framework. Meanwhile, OASIS is developing the Security Assertion Markup Language (SAML) for authentication and authorization, the Extensible Access Control Markup Language, Service Provisioning Markup Language and the XML Common Biometric Format.
The IETF’s work centres on standards for transport-level security on which OASIS and W3C are building application-level security protocols.
The groups need to develop a conceptual “security stack” model that illustrates how various protocols will rely on each other, rather than compete, says Ann Thomas Manes, a security expert who works with OASIS and W3C and is chief technology officer for Web service security vendor Systinet. “The higher-level items take advantage of the lower levels of the stack. So WS-Security depends on XML Digital Signature, XML Encryption, SAML and SOAP,” she says.
Corporations pushing ahead
Such a model is logical, but generates only passing interest from corporations on the cutting edge that want to push their Web services over the firewall now.
“At this point we are using a standard firewall system with Secure Sockets Layer encryption, and we have built our own Web services gateway for authentication and authorization,” says Gereon Fredrickson, senior director of technology products for Galileo International, a provider of data to the travel industry.
While Galileo waits for the interoperability that standards promise, a handful of vendors offer a collection of middleware software and services to boost Web services security, including BEA Systems, Cape Clear, Flamenco, Grand Central Networks, IBM, Iona, Kenamea, Microsoft, Oracle, Sonic, Sun, Systinet and Tibco.
Galileo, which went live with its first external Web service last month, is waiting for the security standards landscape to flatten. “There is still some shake-out that has to happen before we see where the actual standards will settle. Then we’ll see where we can use those,” Fredrickson says.
Signs of a settling have begun in that the WS-Security specification is generally regarded as a competent starting point. It specifies how communication among Web services will be secured and describes how to put security protocols to use within SOAP. WS-Security adds security information to the headers of SOAP messages using XML Encryption, XML Digital Signatures and identity protocols such as SAML or Kerberos, an IETF standard.
“In terms of pure Web services security, we are just starting out,” says Bob Sutor, director of e-business standards strategy for IBM. “But WS-Security starts to lay the foundation.”
Settlement also is happening around workflow specifications that will aid in deploying security at execution points when multiple Web services applications are tied together across a number of organizations.
Last month, IBM and Microsoft combined their respective Web Services Flow Language and XLANG to create the Business Process Execution Language for Web Services. The language lets users specify a collection of Web services and the order in which they need to be executed as part of a business process such as filling an order. It joins similar efforts from Sun on Web Services Choreography Interface and protocols included in OASIS’s electronic business XML specification.
With the stages of a business process defined in a workflow, security tenants such as encryption, authentication and access control can be defined per stage instead of blanketing the transaction as a whole. The workflow lets certain forms of security be applied only where they are needed.
“If you manage the workflow of a transaction, you can trace each step and make sure security is occurring,” says Bernhard Borges, managing director of the advanced technology group at PricewaterhouseCoopers Consulting. He says workflow builds a foundation that finally lets multiple Web services be aggregated into a business transaction.
“Once you get the bits and pieces of workflow, you can start to apply security,” Borges says.
However, experts say it could take two to five years before the standards are mature enough for corporate customers to make use of them.
“Without a security and trust infrastructure, Web services will be dead on arrival,” says Phillip Hallam-Baker, principal scientist for VeriSign. “But people shouldn’t be concerned that this is a problem that won’t get solved, because there is very large agreement on the basic approach on how to go about this.”
– With files from Greg Enright
