RISK NO. 1: Web services isn't secure.
MITIGATION: Choose a standard, but be prepared to switch.
Any plan to expose data and applications beyond the corporate firewall carries risk. Web services adds an extra dose of complexity to a company's IS strategy because there are no agreed-on standards for authenticating users and controlling access to Web services applications that are accessed from outside the corporate firewall. So far, that's deterred many organisations from pursuing one of Web services' grandest promises: That trading partners could assemble application components they need to use at the time of each transaction. For instance, a builder could use one Web service to query catalogues from multiple suppliers, and another one to generate purchase orders to send to two of them. Upon receiving the purchase orders, one supplier could use a Web service to access an internal database and confirm that the order comes from a customer in good standing. The other could use a Web service provided by a third party to run a credit check. The software to run each transaction could be reused multiple times without additional programming. But each of those transactions requires a means to verify that the customer is who she says she is, and that she's authorised to do business.
Secure verification hasn't arrived yet, but early adopters have learned that with planning, it's possible to get around that problem. Wells Fargo's Wholesale Banking unit is rewriting 35 online banking applications for corporate customers as Web services. The applications, now available through the bank's Commercial Electronic Office portal, will be broken up into their discrete components so that customers can pick and choose the features they want to use without having to open entire applications to perform individual tasks. For instance, a company treasurer who wants to make an investment could check her account balances, create a wire transfer, and conduct a trade without having to open and click through three different applications.
The bank has addressed the security conundrum by maintaining its existing methods for customers who want to access its Commercial Electronic Office and transmit data. Customers have to first establish a business relationship with the bank and obtain a user ID and credentials before they can use any online services. Those procedures don't have to change for the bank to make Web services available to customers, says Danny Peltz, senior vice president of Wells Fargo's Wholesale Internet Solutions Group.
The major security challenge Peltz faces - keeping track of which transactions each user is authorised to perform - has less to do with protecting systems and data from unauthorised access than it does with maintaining systems' performance. As each application is currently designed, authorisations are verified when a customer launches the application. Because in the future customers will access Web services instead of launching an application, "the authorisation has to travel with Web services", notes Peltz. "You don't want to have thousands of calls to a database each time there's an authorisation change." Peltz says he expects to choose an industry standard for managing permissions, but observes "there's no clear roadmap for how to do it".
It's possible that no standard will address his needs adequately. But Peltz has built into his strategy the time and money to evaluate different options. His first deployment, at the end of this year, will be a new portal server that supports access to Web services applications through the Commercial Electronic Office portal. Then he'll roll out the actual Web services every quarter through mid-2005. "We're not going to tackle everything all at once," he says.
The US Navy, meanwhile, has decided to adopt Security Assertions Markup Language (SAML), an emerging standard that supports authentication and authorisation of end users. As a member of the Oasis standards body, the Navy has been involved in the development of SAML. "Based on what we know, we think that's a good choice," says Monica Shephard, director of command, control, communications, computer and combat systems for the Navy's Atlantic Fleet. Because Navy personnel are stationed around the globe and support contractors require access to both classified and unclassified information, Shephard says a standard sign-on capability managed as a reusable Web service is essential to ensure that everyone who needs access gets it. And that those who don't, don't.
If the market takes a different tack and the Navy decides to change protocols, Shephard would follow change management policies set out by the Navy's CIO, David Wennegren. To facilitate technical changes, the Navy has spent about $US1 million to develop what it calls a "portal connector", a middleware layer that lets the Navy substitute standards or data definitions without forcing changes to user services or to underlying databases. Shephard has already been through one forced technology change - the choice to adopt new portal software, made by managers of the Navy's enterprise network, the Navy Marine Corps intranet. With that experience behind her, she is confident that she can change Web services standards successfully, if need be.
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.