Web Services for the Financial Sector
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

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.

While Web services are designed to allow applications to communicate with other applications, this communication may occur on behalf of a human end-user. In that case, it may be important for the SOAP message, sent between applications, to contain information about that end user. This information may concern the authentication that was performed by that end-user (e.g. via a password or a smart-card), or information about a grouping to which the user belongs (e.g. “procurement purchasers with authorization to spend up to $20K”). In that case, since a human does not have any direct contact with a Web service, this information must also be included in the SOAP message on their behalf.

Finally, although SOAP is independent of the underlying transport, more often than not it travels over HTTP. This means that XML traffic effectively is disguised as Web browsing traffic, and passes through firewalls as such.

New standards
A number of standards have been developed to address the security deficiencies of XML communication. These include SAML (Security Assertion Markup Language – which expresses authentication, authorization, and entitlement information), XML Encryption (to express encrypted information in XML format), and XML Signature (to express digitally signed information in XML format). WS-Security is used to include security data in SOAP messages. WS-Security was initially proposed by Microsoft, VeriSign and IBM, and is now being developed by OASIS (the Organization for the Advancement of Structured Information Standards). The WS-I (Web Services Interoperability) organization is devising a ‘profile’ for the use of security in SOAP messages. Organizations that are compliant with this profile will be able to claim that their SOAP products are secure.

New products
Traditional firewalls filter data based on the port and the destination. Web services traffic presents a problem for these firewalls because it generally travels over the same port as Web traffic. Another complication is the fact that information about the destination of an XML message is often contained within the message itself. Therefore, in order to filter XML messages effectively, the message itself must be read. Applications which filter XML messages are often called XML firewalls. XML firewalls also validate XML content, for example against XML Schema Definitions, in order to defend against malformed XML messages.

XML firewalling is part of the solution for XML security, but not enough, unfortunately. Recall that security integration is a major challenge for Web services security. Processing XML messages requires links to security infrastructure such as LDAP directories, where roles and entitlements information is stored. Additionally, security integration is required to bind to alerting systems if an unauthorized message is blocked, or to translate between different security token formats.

The combination of XML firewalling and security integration means that organizations can put their existing security infrastructure to work to ensure that they are receiving the right XML data from the correct sources.

Financial services – Web services case scenarios
Outlined below are two standard commercial scenarios from the financial services industry, where banks and insurance companies can use Web services technology securely to integrate with partners and customers.

These examples are notable for the need to reduce the complexity of protocols and transformations required to give customers an integrated view of their accounts and billing details across different products. However, given the sensitive nature of the data, and the need to provide accountability for all transactions at all times, security is a fundamental component of any solution.

Insurance reselling by banks
An insurance company needs to communicate with banks that are reselling insurance as a component part of their financial services products (e.g. mortgages which include house insurance). On a nightly basis, all settlement data relating to the day’s insurance sales are sent automatically in bulk from the banks back to the insurance company.

Prior to the advent of XML and Web services, sending this data would have involved the insurance company and banks reaching agreement on a common software product and a communications protocol. This may have involved a VPN (Virtual Private Network), managed by the insurance company and carrying a large administration overhead, or the use of a third-party EDI (Electronic Data Interchange) VAN (Value-Added Network) to coordinate the bank-insurer communication. Additionally, before XML, it would have involved the bank and insurers agreeing on a common data format.

Partner integration for investment companies
Investment firms have ongoing requirements for systems integration with partner firms. Many wish to create an ‘XML Gateway’ to integrate using Web services with these partners. However, the trading partners accessing these Web services use varying means to present security data in the SOAP message. These include XML-formatted digital signatures, XML-format Kerberos tickets, and SAML Assertions. In addition to dealing with different XML security specifications, the XML Gateway must be capable of processing a large volume of SOAP messages, and validating their content.

As discussed earlier, Web services necessitate new security solutions, which combine XML validation (XML firewalling) with identity verification (via security integration with identity infrastructure). 

In these sample Web services scenarios, the following requirements are important:

* Only SOAP messages targeted at appropriate Web services should be allowed.

* Access control policies should be applicable per Web service, since some Web services may be more sensitive than others. Note that multiple Web services may be located at the same URL.

* The payload of SOAP messages should be examined for integrity, format, and content. Examples of suspect content include large attachments aimed to trigger a Denial of Service (DoS) attack, or data exceeding the bounds of allowed parameters in order to attempt a buffer-overflow attack.

* The speed of the XML filtering solution must not be prohibitively slow, as this would undermine the rationale of deploying XML systems in the first place.

* A new ‘silo’ of user identity information specifically for XML messaging is not practical, since the partners sending and receiving SOAP messages will already have identity management services. Security integration is used to bind to identity services – including older technologies such as PKI (Public Key Infrastructure) as well as newer technologies such as SAML.

Conclusion
Web services are a tempting integration technology, but present new security challenges. These challenges are being met by OASIS and W3C standards such as WS-Security, XML Signature, and XML Encryption. These new technologies are being implemented in security products that filter XML traffic. Security integration is vital, in order to leverage existing security infrastructure for the task of securing XML.

XML does not have to be a ‘dangerous’ technology. With the right security strategy, it is a valuable tool to roll out new services quickly and cheaply.

	Mark O’Neill
	Mark O’Neill is Chief Technology Officer at Vordel, overseeing the development of Vordel’s technical strategy and product development in the areas of XML and security. Mark is a member of the OASIS Security Services Technical Committee, and the author of Web Services Security, published in 2003 by McGraw-Hill/Osborne Media.
	Contact The Author    Vordel