XML.com: XML From the Inside Out
oreilly.comSafari Bookshelf.Conferences.

advertisement

Web Services Security, Part 1
by Bilal Siddiqui | Pages: 1, 2

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:

First Generation Web Services
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.

A Second Generation 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.

A Hotel's Web Service exposing two methods
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.

Resources



1 to 1 of 1
  1. false sense of insecurity
    2003-03-07 15:06:56 Steve Loughran
1 to 1 of 1