Web Services Security, Part 1

March 4, 2003

Bilal Siddiqui

This is the first of a four part series of articles that will examine issues related to web services security. The goal is to explain and demonstrate the use of emerging XML-based security standards from W3C and OASIS. The series will help developers understand:

• the security requirements of web service applications;
• how the different standards fulfill the different security requirements;
• how the different security standards are related to each other; and
• how they coordinate to form modules of the entire web services security architecture.

This first article in the series explains the need for XML-based security standards. The topic of web services security will be addressed from the ground up in this article, starting first by looking at the scenarios in which web services are finding use.

Application Integration

Modern corporate enterprises rely heavily on IT infrastructure to facilitate business processes, reduce the process lifecycle, and manage resources. Organizations with large volume deploy customized applications to manage their internal sales, purchase, payroll, finance, and HR departments. Such applications running within the enterprise need to be integrated with each other for consolidated decision making, accurate system information, and better performance and monitoring.

There are middleware technologies that support custom built systems and integrate applications to produce operational and management efficiency. For instance, Enterprise Application Integration (EAI) is a process that creates an integrated infrastructure within an enterprise. EAI enables the development of software solutions that sit between various applications within an enterprise and package them to harmonize the overall business activity.

Cross-Enterprise Integration

Integration within the enterprise is not enough. Perhaps the greatest advantage of the development of IT infrastructure is that it enables integration of applications across enterprise boundaries, providing fast and seamless collaboration with partners, customers, and suppliers.

Consider a tour operator who designs and offers customizable vacation tours. The tours will contain all the information related to destinations, hotels to stay at, flights to take, etc. As tours are customizable, customers have some level of flexibility in choosing the details of a trip; for example, a vacation tour may offer a choice between different hotels or car rental companies.

How can a tour operator manage the booking of a tour? How does the tour operator make sure that all hotel bookings required for a particular vacation tour are available? How does the tour operator confirm the availability of a chauffeur-driven limousine on a particular date in a particular city?

Surely all this requires communication with partner businesses across the boundaries of the enterprise, whether manually or by computer. The tour operator will get the required confirmations with hotels and car rentals before confirming the package booking to the tourist. Managing all this manually is not a cost-effective and efficient solution. Customers will have long waits for tour confirmations.

Figure 1 represents this concept graphically: the tour operator site is shown talking to a hotel and a car rental company online. The seamless flow of information ensures that vital information is available exactly when and where it is needed.

Figure 1: An Integrated Tourism Supply Chain.

Security in Integrated Solutions

Cross-enterprise exchange of information over the Internet is vital but may have security implications. Security issues over the Internet are important, because it is an insecure and untrustable public network infrastructure, prone to malicious attacks by professional and amateur intruders.

Let's extend the tourism example by assuming that the tour operator is working in an integrated business environment offering tour booking and customized tour planner services via a web interface. All its partner hotels are offering remote access of information such as room rents and availability, booking, discount offers, and special rates for partner companies.

All of the information available for access over the Internet does not have the same level of business confidentiality. For example, room rent information is supposed to be publicly available for everybody, but advance booking service at special discounted rates without advance payment might be limited to partner organizations -- a partner tour -- with whom the hotel has an existing business relationship.

Organizations usually secure company resources available on the network and online services by defining business roles, access rights, and system policies. That's where firewalls, among other mechanisms, have a role to play.

Network Level Firewalls

A network level firewall sits at the doorstep of a private network as a guard and typically provides the following security services:

• monitors all incoming traffic;
• checks the identity of information requesters trying to access specific company resources;
• authenticates users based on their identities, which can be the network addresses of service requesters or security tokens;
• checks security and business policies to filter access requests and verify whether the service requester has the right to access the intended resource; and
• provides for encrypted messages so that confidential business information can be sent across the untrusted Internet privately.

Figure 2 graphically demonstrates the operation of a firewall, protecting the physical boundaries of a network: there is a physical boundary of the private network and the only way to get into the network is through the firewall. While packets of network traffic and messages pass through a firewall, they are authenticated and checked for possible intrusion or malicious attacks.

Figure 2: A Network Level Firewall Providing Security to an Intranet.

Only this brief explanation of firewalls will be presented here, intended to emphasize their relatively coarse-grained protection. See the links at the bottom of this article for further reading on firewalls.

Interoperability and Service Oriented Architecture (SOA)

When a tour operator designs a vacation tour, it relies on efficient application integration with its partners. But the tour operator cannot control and may not even know much about the IT infrastructure of partner companies. For example, the tour operator might be using a Java solution over Solaris servers and partner hotels may be using .NET or some other technology. How can interoperability between the two systems be ensured?

It is not feasible to sit down with all partner hotels and decide about messaging formats for exchange of information and interoperability. This will create an endless task of designing and redesigning message formats for each partner hotel. The cost of this type of legacy integration is so high that such techniques are only feasible in high IT return sectors like airline and banking industries. Most B2B e-commerce isn't able to justify IT infrastructure development costs in this way.

But if applications shift from legacy integration to the Service Oriented Architecture (SOA) provided by web services, what are the benefits and how does such a shift ensure interoperability?

RPC-like Remote Calls in Service Oriented Architecture

The term service is used for applications that can respond to external calls for functionality. Services in SOAs are similar to classes in object-oriented languages; both can service calls to their methods. The only difference is that services in SOA are truly distributed: they form a distributed system architecture and are independent of their own or the caller's location.

Service-orientation stems from the proven and well-known object oriented programming basics. The concepts of abstraction and encapsulation were developed in the early days of OOP, owing to their importance in developing reusable software components and class libraries. According to the OOP basics, a class or an object is wrapped inside a boundary and a well-defined interface is exposed to other objects for interaction.

This concept is depicted in Figure 3 in UML notation, where a class named Hotel is exposing its method named GetSpecialDiscountedBookingForPartners. Another class named TourOperator is shown invoking the GetSpecialDiscountedBookingForPartners method of the Hotel class. SOA applies the same concept to objects hosted on web servers. You develop classes (e.g. a JavaBean named Hotel) to implement your business logic and expose the functionality of your classes by hosting them on SOAP server. This is illustrated in Figure 4.

Figure 3: The Hotel class is exposing its method and the TourOperator class is invoking it.

Figure 4: A SOAP server exposing the functionality of a class over HTTP

It shows the same Hotel class as Figure 3 hosted on a SOAP server. The only need for the SOAP server is that it works over HTTP. Effectively, this architecture provides remote invocation functionality to your classes. Therefore, once hosted on a SOAP server, our Hotel class has now become part of a global tourism application, whose other components (e.g. TourOperator) are hosted on SOAP servers all over the Internet.

SOAP uses XML to specify remote method invocation calls. For the sake of demonstration, I have provided a sample SOAP request-response pair in Listings 1 and 2. Listing 1 is a sample SOAP request message that comes from a tour operator's web service to invoke the GetSpecialDiscountedBookingForPartners method of the hotel's web service. Listing 2 is the sample SOAP message that will be sent in response.

First, Second and Third Generation Web Services

We have seen the request-response style of remote invocation of SOAP services using HTTP. A SOAP request message carries a remote method invocation call to the SOAP server. The SOAP server invokes that particular method and prepares a response and sends it back.

How does a SOAP server manage to author a SOAP response? Depending upon how a SOAP request is handled inside a SOAP server, and then inside the class hosted on the SOAP server, web service applications can be classified into three generations ranging from their humble beginnings as simple RPC-like remote calls, to the second generation federated applications, and finally to the third generation of transactional web services.

The first generation of web services presents a simple one to one interaction. The execution process lies entirely within a service domain and does not depend on other external services. The sequence of operations in first generation web service applications is shown graphically is Figure 5 and explained below:

Figure 5: First Generation Web Services

1. A requesting application will send a request message to a SOAP server.
2. The SOAP server invokes the internal class implementing the service in question.
3. The class performs the tasks required by the job (e.g. reading from an internal database) and returns to the SOAP server.
4. The SOAP server eventually authors the SOAP response and sends the response back to the requesting application over HTTP.

Second generation web services federate or distribute the processing of method invocation calls to other web service applications. This is shown graphically in Figure 6, where a tour operator's SOAP server receives a web service method invocation call. The tour operator's SOAP server in turn calls the hotel's SOAP server to do part of the job. In this way, web services are chained one after the other to perform the desired operation. This type of chained application is sometimes referred to as federated web service application.

Figure 6: A Second Generation Federated Web Service Application

Third generation web services are a logical extension of the second generation applications. When the federated chain becomes too long or the business logic is inherently complex, federated applications take the form of web service transactions. For example, consider a vacation tour that involves a chain of a dozen hotel, air line, and car rental bookings. When a tour operator tries to confirm the entire chain, it may find that one of the hotels is already booked and unavailable for further reservations. In this case, it needs to hold on the bookings that are available and give some options to the customer. For example, it may offer alternate hotels. After the customer has decided on a new hotel, the bookings on hold can be released or confirmed.

Security Requirements for SOAP-based Web Services

Let's return to the tourism example. Have a look at Figure 7, where the Hotel web service exposes two methods: GetBooking and GetSpecialDiscountedBookingForPartners. Let's assume that the GetBooking method is meant for public use: anyone can access this method to get a room reservation. On the other hand, the GetSpecialDiscountedBookingForPartners method is meant to be strictly private between partner companies. Only a partner tour operator, with whom the hotel has an established business relationship, should be able to access special discounted reservation rates.

Figure 7: A Hotel's Web Service exposing two methods

Is it possible to achieve this type of security with network-level firewalls? A SOAP server holds only the information related to the web services it is hosting (names of the services, names of the methods in each service, where to find the actual classes that implement the web services, and so on) and has the capability of processing incoming SOAP requests. However, the SOAP server itself doesn't have any capability to check whether the incoming SOAP request is coming from an anonymous customer or a known business partner. SOAP cannot distinguish between sensitive and non-sensitive web services and cannot perform user authentication, authorization, and access control.

It is clear that a remote client which has accessed a SOAP server enjoys the opportunity of invoking any method of any services hosted on the particular SOAP server. Some readers might have correctly concluded that it is not safe to host web services of different levels of sensitivity on the same SOAP server.

Even if you deploy a network-level firewall to protect from intruders, you will not be able to distinguish between a customer and a partner once it has reached the SOAP server. It is possible that an intruder authenticates himself as an anonymous customer, reaches the SOAP server, and invokes sensitive web services meant for partners. Thus, a SOAP server is like a hole in your network.

There are two solutions to this problem:

1. Use a different SOAP server for each level of sensitivity, so that different authentication policies can be enforced on each sensitivity level. This solution may seem appropriate for web services today. However the real advantage of web services lies in the next generations where web services will not just be invoked by browser-assisted human clients, but web services will invoke each other to form chained or transactional operations. Such complex web service infrastructure will be very hard and expensive to build with the idea of having a separate SOAP server for each authorization policy. In addition, this idea hardly allows building reusable or off-the-shelf security solutions.

2. The second option is to make the firewall XML and SOAP aware. The firewall will be able to inspect SOAP messages, trying to match user roles with access lists, policy levels, and so on. This solution is a better approach. It also allows building XML-based standard security protocols, which can be adopted by security vendors to ensure interoperability.

   Web service users can add security information (signature, security tokens, algorithm names) inside SOAP messages, according to the XML-based security protocols. The XML and SOAP-aware firewall will check the message before it reaches the SOAP server, so that it is able to detect and stop intruders before they are able to reach the service.

Based on the second approach described above, W3C and OASIS are developing several XML-based security protocols. These protocols will define the various security features of an XML and SOAP-aware firewall.

XML Security for Web Services

This section very briefly discusses the high level features of some of the security protocols from W3C and OASIS. Upcoming articles in this series will discuss the details of all the XML security protocols individually, and how they coordinate with each other to form modules of an "XML firewall."

Although specs are noted as being "from W3C", or "from OASIS", readers should note that the procedures for the creation of specifications under these two bodies differ significantly. For details of OASIS' process, see Jon Bosak's "A Scalable Process for Information Standards", and for W3C, see their Process Document.

The XML Signature specification is a joint effort of W3C and IETF. It aims to provide data integrity and authentication (both message and signer authentication) features, wrapped inside XML format.

W3C's XML Encryption specification addresses the issue of data confidentiality using encryption techniques. Encrypted data is wrapped inside XML tags defined by the XML Encryption specification.

WS-Security from OASIS defines the mechanism for including integrity, confidentiality, and single message authentication features within a SOAP message. WS-Security makes use of the XML Signature and XML Encryption specifications and defines how to include digital signatures, message digests, and encrypted data in a SOAP message.

Security Assertion Markup Language (SAML) from OASIS provides a means for partner applications to share user authentication and authorization information. This is essentially the single sign-on (SSO) feature being offered by all major vendors in their e-commerce products. In the absence of any standard protocol on sharing authentication information, vendors normally use cookies in HTTP communication to implement SSO. With the advent of SAML, this same data can be wrapped inside XML in a standard way, so that cookies are not needed and interoperable SSO can be achieved.

eXtensible Access Control Markup Language (XACML) presented by OASIS lets you express your authorization and access policies in XML. XACML defines a vocabulary to specify subjects, rights, objects, and conditions -- the essential bits of all authorization policies in today's e-commerce applications.

Summary

This article has set the scene for this series on web services security, by introducing the usage scenarios for web services, some of the problems that need solving, and the basic specifications under development to address these problems.

The next article in this series will discuss the syntax of the XML Signature and XML Encryption specifications and how WS-Security uses them.