Web Services Security, Part 1
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.
Pages: 1, 2 |
