Web Services for the Financial Sector
By Mark O’Neill
September 18, 2003

Summary: Web services are a tempting integration technology, but present new security challenges for financial services companies. By Mark O’Neill.

Full Text (Page 1 of 3)  

New efficiencies
In the mid to late 1990s, the Web exploded as a medium for communication. The trigger for this explosion was the availability of open standards that were relatively simple to use, the most important being HTML and HTTP. At the same time, application-to-application integration continued to be beset by incompatibility. It was obvious that application-to-application integration could benefit by following the approach of the Web, by using open and interoperable standards. Thus, XML and SOAP were devised. XML - eXtensible Markup Language - is used to describe data in a platform independent manner and is an evolution of the older SGML. SOAP is used to envelope XML data when it is sent between applications.

Technologies such as XML and SOAP make it easier for applications to communicate with other applications. One system accesses the other system as a ‘service’, using a software architecture called services-oriented architecture. Since the communication uses Web technology, this architecture has been named Web services. Web services present an attractive architecture for financial services companies. Sample uses include:

* Communications between insurance companies and banks who resell insurance as part of financial services products.

* Brokerages communicating with trading systems.

* Streamlining internal software integration, to use open standards rather than proprietary APIs (Application Programming Interface) and middleware products.

The third example in the list above should make it clear that, despite the name, Web services do not necessarily mean doing business across the Web. When Web technologies are used internally for software integration, it also counts as Web services. Indeed, internal software products are where the vast majority of Web services projects are taking place, and where the initial cost savings are being enjoyed.

New challenges
Unfortunately, the picture is not entirely rosy. Web services present security challenges for a number of reasons. The first challenge is security integration. Even internally on a company’s private network, XML traffic may travel across a number of security contexts. For example, a user may log on to an intranet portal and then request a report which is fetched via SOAP from a database: therefore the user’s profile at the intranet portal must be matched with their profile at the database. The picture is further complicated when different security technologies are mixed; for example, if an end user authenticates using a password but must access a Web service that consumes digital certificates. The challenge of security integration is itself being addressed by XML technologies, such as SAML, WS-Trust, and WS-Federation. However, much of the security integration involves non-XML technologies such as LDAP.

SOAP messages are independent of the underlying network communications. SOAP messages can be sent by email, FTP, or over the Web. This independence means that SOAP cannot rely on the security in the underlying network. In addition, a single SOAP message may traverse a number of networks, in a similar manner to how an email message may pass through a number of email servers en route to its recipient. Since these intermediate systems may not be trusted, the SOAP message itself must be secured. The WS-Security specification describes which security in the form of encryption and digital signatures may be applied to SOAP messages.