eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Gwen Alexander Moertel isnt the cheerleader type who jumps on every technology trend. But when the IT director for Wachovia Securities Inc.s Equity Capital Markets division heard about Web services last year, she quickly became a true believer.
So sure was Moertel that Web services would be the best way to help the division speed critical financial information to investment banking clients that she was willing to work around the security holes that have kept many enterprises away from Web services. Early this year, after discussions with developers at her company about the lack of security in Simple Object Access Protocol, Moertel launched a Web services-based system using Grand Central Communications Inc.s secure Web services network.
“Security is a weakest-link discipline, and there are certainly a few internal audit people that are not very pleased with SOAP,” Moertel said. “Until theres a standard way to secure Web services, you have to be creative.”
Web services hype focuses on the technologys ease of development and interoperability, but security remains the major obstacle keeping most enterprises from deploying Web services-based systems that reach outside their firewalls. Without security standards built into SOAP and other core Web services technologies—standards that wont solidify for nine months or more —many enterprises are restricting Web services to pilot projects.
But some organizations, such as Wachovia, cant afford to wait. They are starting to adopt Web services, even if it means taking an ad hoc, labor-intensive approach to making them secure. Wachovia and other companies are paying service providers to manage and secure their external Web services transactions. Others are deploying multiple layers of security, such as Web access control agents, multiple user names and passwords.
Launching into Web services before theres a standard way to secure the technologies is not for everyone. Only the most motivated should attempt it, experts say. “Security is such a big issue with Web services, and its still awfully early in the game,” said Jamie Lewis, CEO of The Burton Group Corp., a networking consulting company in Midvale, Utah. “That will and should give most enterprises pause before going forward with something they cant easily pull back from.”
Battling Standards
Currently, two competing Web services security standard initiatives—SAML (Security Assertion Markup Language) from the Organization for the Advancement of Structured Information Standards and WS-Security (Web Services-Security) from IBM, Microsoft Corp. and VeriSign Inc.—are making the most headway in providing a security framework for Web services. But it remains to be seen which security specification will dominate after both are submitted for recommendation to standards bodies such as the World Wide Web Consortium, which maintains the SOAP standard.
“Its unclear how things will shake out right now, so our advice with Web services is to start getting a feel for the technologies by working with standards you know are set,” Lewis said. “You can be certain standards like XML, SOAP, UDDI [Universal Description, Discovery and Integration] and WSDL [Web Services Description Language] will continue to dominate the Web services scene.”
Officials at Fiserv Inc., in Brookfield, Wis., are heeding that advice. Greg Bakke, director of systems development for the companys Trust Services Group, has invested in Sun Microsystems Inc.s Java 2 Platform Enterprise Edition and in Microsofts .Net frameworks, and Bakke is using SilverStream Software Inc.s Extend application server and application composer products on legacy systems integration projects. But so far, because of security concerns, hes held off deploying full-fledged Web services that work over the public Internet for the companys Trust Services Group, which administers more than 217,000 Individual Retirement Accounts and business retirement plans.
“Were not fully on board with Web services because of the lack of security built into SOAP,” Bakke said. “Were currently trying to figure out what we want to expose publicly through Web services, and were hoping a standard will come along while were doing our research.”
In the meantime, Bakke is working with consultants from SilverStream, in Billerica, Mass., to determine a way to securely build Web services that allow employees across all divisions at Fiserv to share information and applications. Because each Fiserv division is on its own network, any exchange of information would be exposed on the public Internet.
The Web services application Bakke would like to roll out would allow the Trust Services Group to submit stock trades to the companys Fiserv Securities brokerage arm. Hes got his team working on it. And in case a security standard fails to emerge before the application is ready for deployment, he said hes looking at using the standard HTTPS (Secure HTTP) to provide encryption and basic point-to-point authentication for the exchange of information via Web services. The group also has experience with Triple Data Encryption Standard and nonrepudiation and has built a few frameworks throughout the company aimed at solving single-sign-on issues across multiple platforms. But, Bakke said, cobbling together such technologies to secure Web services would not be his first choice.
“Were not comfortable exposing information until the specs are ready, even though were ready to start using a Web services framework,” Bakke said. “We can still use our Web services framework, just not exposed over the public Internet.”
Some companies, however, arent waiting for the W3C to release a standard. Vendors such as IBM and Systinet Corp. have begun releasing tool kits that use new, unapproved security specifications in an early effort to close the security gaps.
Most recently, IBM released its Web Services Toolkit 3.1 last month, using the first implementation of the WS-Security specification. And next month, Systinet plans to release its WASP (Web Application and Services Platform) Secure Identity product, which uses SAML as one of its protocols. Microsoft is expected to release its own tool kits to support its WS-Security specification while Sun will release tool kits based on SAML. Products from several security vendors are expected to follow.
And some users are attempting to patch Web services security holes in advance of standards. For them, the downside is that IT managers must take on more time-consuming management tasks. At public utility Portland General Electric Co., in Portland, Ore., for example, Andy Tauber, senior software consultant, decided to roll out customer account portals using Web services secured by several layers of technology, including Secure Sockets Layer encryption, a VPN (virtual private network) and HTTPS. That, however, meant Tauber had to take on the task of issuing and managing multiple passwords for each user. To alleviate that headache, Tauber is turning to new single-sign-on products that will enable customers to access all PGEs Web sites using a single password.
Tauber, who deployed Microsofts Active Directory last October, chose to use DirectorySmart from OpenNetwork Corp., in Clearwater, Fla. OpenNetwork provides a WAC (Web access control) agent in the Internet server API filter. Any time there is an HTTP request to a PGE Web server, the WAC will look up the request, determine the type of request and authorize the user to view the content. Tauber is also using secure keys for VPN access and communicates through firewalls between application and Web servers via SOAP messages.
“There are standards coming, but its kind of a mixed blessing because we are now committed to what weve deployed,” said Tauber. “But we needed to roll out Web services as soon as possible. There was no choice but to manage multiple layers of security.”
At Wachovia, Moertel decided shed have a third party manage those security layers for her—a solution her security team easily went along with. Wachovias Equity Capital Markets division delivers research to investment banking clients and needed rapid access to data sources such as First Call from Thomson Financial, a division of Thomson Corp., in Stamford, Conn. Prior to moving to Web services, Moertel created separate FTP-based systems to receive and send Thomson data, which drained IT resources. The process was slow and expensive considering the hardware and maintenance costs involved.
To replace that, Moertel asked Thomson to connect to its clients using Grand Centrals network. Wachovia connected its employee portal to the providers private network via SOAP. On its side, Thomson used Microsofts ASP .Net development tool to create a connection to the Grand Central network. Today, Wachovia makes an HTTPS request by sending a SOAP message to get data from Thomson, and Thomson sends the information back to Wachovia via SOAP and XML. The entire transaction happens in real time and more reliably than using FTP.
The process took five weeks to set up and went live within eight weeks. Moertel estimates that the expense of using the Grand Central network was only 5 to 10 percent of what it would have cost for Wachovias Equity Group to develop and maintain the same capabilities internally. She also said it would have taken too long to build internally because several units, including security, firewall and database groups, would have had to review all the initiatives before Wachovia could begin exchanging data with its partners.
“I told them I wanted to make an HTTPS request that would be encrypted, and the firewall guys were fine with it,” Moertel said. “Even with SOAP, because of the uniqueness of the IDs and the cues we use, its not easy to just write some random SOAP message and break in.”
Moertel may be on the cutting edge with Web services but, even for her, there are limits. Wachovia has no plans to use Web services for mission-critical applications such as trading. The security concerns and the potential lag time, she said, are just too great right now.
“Research is obviously very important, and our Web services solution hasnt gone down once,” Moertel said. “But I dont think well ever use Web services to run trades because our trading systems right now are hardwired. Im never going to use Web services to send instructions for my million-dollar trades.”
Related Stories:
- Web Services Security: A Political Battlefield
- Web Services Edged Forward
- IBM and Systinet Write Next-Gen Tools