Columns
Securing Web Services
The upcoming SAML standard should help promote distributed, Web-services transactions, giving e-commerce an upgrade. But don't rush in; it's still only a framework.
Web services—one of the latest waves in business and technology—is closer to reality now that we almost have an agreed-upon security framework: Security Assertions Markup Language (SAML). It may soon be possible for companies to use Web services securely.
That's the potential. Now for the kicker: The economic landscape is littered with the skeletons of many such movements. Like Web services, the hype surrounding push technology and b-to-b portals was almost hysterical. While some initiatives produced interesting changes, few (since the Internet) created radical new paradigm shifts or revolutionized the way business does business.
While Web services have potential (see "Great Potential"), they're but a framework, albeit a valuable one. The total market for Web-services software, services and hardware will jump from $1.6 billion in 2004 to $34 billion by 2007, predicts research firm IDC.
It's useful to note that SAML 1.0 is apparently nearing ratification by the Organization for Advancement of Structured Information Standards (OASIS), a consortium for creating XML-based interoperability specifications. SAML encodes authentication and authorizations into Web-services transactions by using such standards as Extensible Markup Language (XML), Simple Object Access Protocol (SOAP) and XML Digital Signatures (XML-DSig) to secure transactions in a Web-services environment.
SAML came about because of competing ways of implementing access control, authorization, and single sign on to Web-based systems. "Every vendor had its own, different approach" in addition to a raft of companies building their own homegrown database solutions, leading to silos of hard-to-share information, says John Pescatore, an analyst at Gartner Inc.
"Web services," usually means a combination of SOAP for wrapping up calls, XML for the business logic, and HTTP to transport the wrapper back and forth. SAML allows the wrapper to be encoded in interesting ways.
To explain some of the interesting aspects of security, take a look at how Web services work. "Right now, a computer program is broken up into a lot of procedure calls," says Gartner Inc. analyst Rob Batchelder. With Web services, however, "the whole idea is to be able to remotely invoke procedure calls across a network." One business can, for instance, access the application logic at another business. Web services let businesses trade information about how to encode calls and responses.
Technically speaking, a procedure call wraps the request in SOAP—or another transport protocol such as ebXML or Biztalk—and an XML document exchange framework. That request is sent over an agreed-upon transport mechanism (such as HTTP, SMTP or FTP). At the target site, a SAML-aware server listens for incoming SOAP calls, decodes the XML business logic and applies it to the relevant application. The results of that process are then output in XML, wrapped up in SOAP, and sent back to the initiator.
In contemporary b-to-b transactions, one site communicates with one other site. Web services are decentralized—various application calls can be farmed out to different sites, some operating dependently or independently of each other, all in peer-to-peer fashion. Any machine, anywhere, can do things for the requesting machine. Instead of running applications on one machine, the user tells a network to "just do it."
Yet another interesting example is a customer support application, say for telecommunications companies. Currently, customer support representatives may have up to 15 different applications, says Batchelder, each requiring a unique password. Using a Web-services model to link all of the applications into one employee interface would save valuable time for both representatives and customers, especially if customers can use the applications themselves.
Potential for Damage High
The potential for damage is great. With companies trading application logic and opening their systems to others, bogus application logic or hacker-triggered XML buffer overflow attacks could cripple the receiving Web application or even the company itself.
That's why security is so important, and how SAML comes in. If anyone can make a procedure call to anyone else, then a sophisticated way of ensuring your machines automatically talk to a specified incoming application logic is crucial. SAML assertions are bound to the document header of SOAP transactions and can initiate transactions in the target Web services application that push or pull relevant security information for establishing which procedure calls are from those within a Web of trust.
SAML doesn't create a new kind of cryptography or security, allow sites to negotiate with each other, or give them ready-made authorization policies. It simply helps secure transactions by describing appropriate security technologies and information in XML format. In particular, SAML asserts in XML format such things as a unique identifier or length of allowed session time. A SAML specification could articulate conditions, such as authentication being predicated on someone else's authentication, for example. In addition, the SAML assertion can have a record of why access privileges were granted, so application logic could analyze the rationale and either approve or disapprove. Much is possible.
SAML can authenticate decentralized transactions, allowing sites to know who's trusted and who's not, how trusted they are, and why they were trusted in the first place, in case the target system's security logic doesn't like what it sees.
Great Potential SAML could mean the growth of brokered financial transactions for b-to-c sites such as online retailers, which contract with a credit-card clearing agency. What if clearing became decentralized, and thousands of brokers offered real-time rates? It could happen: "All financial transactions like that can be brokered," says Batchelder. "It would be like Priceline; [brokers] will aggregate it all up and see who's offering the cheapest buy and sell." Then, clients—or, to be more precise, their applications—could pick the best deal at any given moment. Security frameworks such as SAML would communicate the level of broker security—how "trusted" they are—between whatever security software the various companies are using, so that before choosing to buy/sell with a broker, the overall security of the transaction could be considered as well. Online vendors could sign up with more than one credit-card clearing agency. With Web services, vendors' code could automatically negotiate with credit-card clearing brokers at the exact moment of a customer's purchase. The agency with the best quote could be signed up by the retailer to execute that single transaction. The security frameworks at both sites would exchange information, having verified the levels of security. The transaction is completed and the retailer is paid. There are also b-to-b examples. "Let's say you're FedEx, buying an airplane for cargo from Boeing," says Batchelder. That plane will have such things as avionics, jet engines and seat configurations, and FedEx will need to configure it all. Now, let's say Boeing offers engines from various manufacturers—General Electric, Pratt & Whitney, etc.—customers will theoretically be able to go onto the Boeing site, which will act as a portal for all of the component configuration information. "Boeing, for example, might be the portal, but what Boeing will be doing is dispatching a lot of requests over to GE" and the other suppliers, says Batchelder. The benefit would be that Boeing gets only up-to-date configuration information from suppliers, and that users see it all in one place without having to log onto multiple Web sites. Once a transaction took place, the Boeing portal could send out bits of application logic to schedule and order the appropriate components for the job. —M.S. | |
Time to Jump in?
Should your company run out and adopt Web services and SAML? In the short term, "Make sure your vendors support SAML, so that you'll have a standard," recommends Gartner's Pescatore. Vendors such as IBM, Baltimore and Netegrity are already building products around SAML, but the standards need to be finalized; the initiative has been dragging on longer than anyone expected. A sticking point: How far security should go in SAML version 1. If too weak, future SAML versions will be less secure to maintain compliance with its predecessor's schema.
Some experts wonder if Web services will work out at all. "Web services is the big wild card, in my view, because although Web services is being sold by the major players—particularly Sun, IBM and Microsoft—as the continuation of the ASP business model, the ASP business model didn't work so well," says Clay Shirky. Shirky is a New York-based writer, consultant and senior analyst with O'Reilly & Associates Inc. who follows peer-to-peer technologies and Web services.
Shirky notes a paradox with current Web-services thinking. "The Internet works because it gives you three things—you can get, put or post," he says. "If Web services is going to be like the Internet, but extensible, as some have said, then it's not really like the Internet at all. In essence, it's trying to be everything to everyone." Where's the big benefit?
The Microsoft X-Factor
To complicate matters: The extent to which Microsoft's own Web-services initiative, .NET, will play with generic, open-source Web services. In the past, Microsoft has often put a proprietary spin on what were supposed to be true open-source initiatives, such as Sun's Java. So when open-source Web services touch .NET, will they get along? We can only hope. SAML—a generic way to trade security schema—competes with Microsoft's Passport, its system for asserting identity across .NET and its various Internet properties, as well as Microsoft's own Web services security initiative, dubbed WS-Security.
WS-Security, says Gartner's Pescatore, presumes to be the final word in Web services security, but it's just too big a specification, too soon. "We don't need seven layers of security processing," he notes, since currently Web services aren't used for anything beyond application integration.
A battle is brewing. Sun Microsystems-led "Liberty Alliance" is trying to secure interoperability guarantees from all players, though even it hasn't signed off on the OASIS SAML specification yet. Microsoft has so far eschewed the alliance for what it says are cultural reasons, while saying it hopes to have .NET interoperate seamlessly with the general Web-services paradigm. Even if Microsoft doesn't embrace SAML, however, current pure Microsoft Web Standards shops would include Active Directory and Kerberos. "You could spin Kerberos tickets as a way to carry SAML's assertions," says Pescatore. Thus SAML could bridge the Unix and Microsoft worlds.
In April, RSA Security agreed to freely license to vendors two patents it believes cover SAML. There's a catch: All vendors having intellectual property that might apply to SAML must also reciprocate with royalty-free licenses. Though no other company has yet stepped forward saying it has intellecutal property that pertains, it does add yet another wild card to SAML.
Time will tell if Web services is a business revolution or not, but getting it secured and giving companies a rudimentary security interoperability standard is a step in the right direction.