In-Depth
Case Study: Circumventing Web Services Security Problems
Aeroplan adopts an XML firewall
When Aeroplan, an airline affinity program owned by Air Canada with over six million members worldwide, decided to rapidly expand its partnership program, it needed a secure way to bridge its XML infrastructure with partners’ systems.
“About a year ago, we initiated a project to look for technology to enable us to expose some of the existing XML services we had in place … to external partners via the Internet,” says Spyros Kattou, e-business architect for Aeroplan. Management wanted to rapidly expand the rewards options offered to members by bringing in new partners. After researching options, Kattou decided Web services was the best approach.
Based in Montreal, Aeroplan has 176 managerial employees and over 1,300 call center agents. The company offers programs with over 100 other companies, including airlines, hotels, and car-rental agencies. This year, for the second year in a row, it was voted the Official Airline Guide’s best frequent-flier program.
Making the jump from XML to SOAP XML-based Web services wouldn’t be easy, however. Four years ago, when Aeroplan chose XML as a message-exchange format, there were few standards; it had to create its own XML formats. Today, “those XML services are not Web-enabled,” notes Kattou. “So a big mandate was, we did not want to rewrite those services and open up the code to this kind of Web and IVR code for Web services. We just wanted to open up a real-time channel, if you like, to our partners.” Of course, “once you expose your XML services as Web services, they’re Internet-facing, and anyone could attack them,” notes Kattou.
Security concerns aside, another hurdle was portable bridging—to adapt the IBM MQSeries transport-layer protocols Aeroplan uses, which are TCP/IP-based, to work with HTTP (and HTTPS). The company also wanted an easy way to filter out XML tags partners shouldn’t see.
Aeroplan’s initial idea was to build its own software, but Kattou nixed that approach based on infrastructure and labor costs. He began investigating available technology, narrowing his choices down to two companies: Reactivity and Westbridge.
“On paper, they both had everything we needed, except the portable bridging … So we approached them both and said … we think you have everything we need, except this one thing,” says Kattou.
Though Reactivity hadn’t been planning to introduce portable bridging until 2004, “they basically built this functionality within two to three weeks,” he notes. Westbridge, however, “was a little more hesitant—they wanted to charge us for that; it was a little more bureaucratic, getting around it.” In November 2003, Reactivity demonstrated its proof of concept for two days, taking just two hours to get the appliance set up and the first Web service exposed. “I prepared a barrage of tests for the proof of concept, and it pretty much passed everything,” says Kattou, “[proving] to us that what was on paper was reality.”
Due to time restrictions, Aeroplan didn’t vet another company’s product via a proof of concept. Kattou got approval to purchase two Reactivity XML Firewalls in December, and had them in place by January 19, 2004. “Since then, we put it into production, and knock on wood, everything is fine.”
The only installation hiccup was special-ordering a rack from Vancouver to fit the Reacativity boxes, which required a different size than the one used in Aeroplan’s data center (hosted by IBM Global Services in Winnipeg). “Everything else was easy—network firewall configurations, those kinds of things,” says Kattou.
The XML Firewalls give Aeroplan a range of Web services security features: IP filtering to restrict access to partners, authentication via security tokens and X.509 certificates (to counter IP spoofing), and SSL to keep transmissions private.
For managing security policies, Kattou says he likes the firewall’s Web-based graphical user interface. “We can control who has access to what, basically within seconds … without interfering with existing production traffic. That’s very liberating … as opposed to having to call a programmer who has to code changes, and it taking days or weeks before it’s done.” Today the average time to add a partner via Web services is less than an hour.
Here’s how it works: Aeroplan exposes the relevant Web services, then generates a Work-Flow Description Language (WFDL) file, which it e-mails to the other company. The partner then generates its XML file according to WFDL specifications, and returns the information. “It’s very automated … and very error free, because there’s less human intervention on the client side in coding those messages, so it’s accelerated our cycle of bringing on partners, or even expanding partners’ capabilities,” says Kattouu.
In terms of supporting its hardware, “Reactivity has been very good about responding to some of our requests,” he says. For example, Aeroplan’s backend XML system wasn’t properly feeding some characters to the mainframe. “If there was a French character in the message, we found that it was not being decoded properly” by Aeroplan’s system (not the firewall, he notes), due to incorrect use of headers. Yet recoding Aeroplan’s code would have been a huge undertaking, so it asked Reactivity whether it could intercept messages and add relevant headers where necessary.
Reactivity began development of the feature, and “within about a month, we had the functionality available to us,” says Kattou. “For us, that gave us a good feeling that post-sale the company was open to listening to our needs and reacting to our needs and solving problems for us, which was very important.”
With that flexibility in mind, Kattou says, “I have to say that Reactivity has pleasantly surprised us,” especially since “they’re a small company.”
One feature Kattou is hoping for in the future is an easier way to advance Web services applications and XML Firewall settings through development, research, testing, quality assurance, and into production. “I know they’re planning a lot of new functionality coming up,” he says. “It’s not by any means something that’s preventing us from doing what we need to do. It’s simply to make it easier.”
Related Articles
Top Three Security Problems Remain Despite Increased Spending
http://www.esj.com/security/article.asp?EditorialsID=860
Web Services: Protecting Yourself from Partners' Security Problems
http://www.esj.com/security/article.asp?EditorialsID=573
About the Author
Mathew Schwartz is a Contributing Editor for Enterprise Systems and is its Security Strategies column, as well as being a long-time contributor to the company's print publications. Mr. Schwartz is also a security and technology freelance writer.