Securing Web Services with WS-Security: Demystifying WS-Security, WS-Policy, SAML, XML Signature, and XML Encryption

2017-07-07 02:10:07

< Day Day Up >

WSDL: Schema for XML/SOAP Objects and Interfaces

Web Services Description Language (WSDL) is typically produced by the development tools used to create the Web services. It describes what functionality the Web service provides, how it communicates, and where to find it. WSDL is divided into a what part, a how part, and a where part. The what part is the abstract interface much like Interface Description Languages (IDLs) of past generations of middleware. The how part maps the abstract interface onto a concrete set of communication protocols. The how part is called a binding. The where part defines a specific Web service implementation specified through a typical Web URL.

Where WSDL Came From and Why It's Important

WSDL is an XML language that describes a Web service. When we described a "contract" for service-oriented architectures earlier, the contract we were referring to was the WSDL file. It describes what functionality a Web service offers, how it communicates, and where to find it.

The earliest direct ancestor to WSDL is probably the Web Interface Definition Language (WIDL) from WebMethods. Like the IDLs from CORBA and COM, WIDL created a separate language-independent description of an interface to a service, but in XML format. A similar effort led to the Service Description Language (SDL) from Microsoft. And in another parallel effort, IBM had the Network Accessible Service Specification Language (NASSL). These efforts coalesced into WSDL, driven by Microsoft, IBM, and Ariba. This group submitted WSDL 1.1 to the W3C in March 2001, where it immediately gained the support of 22 other members . It remains officially categorized as a W3C note; however, it has languished a bit in the W3C but will continue to have broad-based support, solidifying its role as the de facto standard way to specify a Web service description.

We cannot overstate how important of a complement WSDL is to SOAP. Developers need WSDL to read SOAP interfaces directly into their programming tools.

Programming tools then present the WSDL-defined remote procedure calls as if they were local method calls in the programming language used by the tool. To the developer, calling one of these WSDL RPCs looks no different than calling a method on a local object. Operationally oriented monitoring and analysis systems also use the WSDL to understand the XML Schema that defines the XML messages such a tool is trying to observe.

This is an important point: Technically, WSDL creates a schema for XML/SOAP objects and interfaces. It's like a user 's manual for XML/SOAP objects; like a resume for a Web service. Developers (or most often, their tools) read a WSDL document to understand what SOAP calls are required. Many development tools such as JBuilder, Visual Studio .NET, and WebLogic Workshop import the WSDL directly into the development tool to generate SOAP calls automatically from the description. Runtime tools operate the same way and use the WSDL to determine how to monitor, manage, and control Web services in production.

Services are described in a WSDL document as a collection of endpoints called ports . Ports perform specific operations on messages. Messages contain either document-oriented or procedure-oriented information as controlled by the binding style attribute. This information may be used to select an appropriate programming model: either RPC- or DOM-based.

If the operation style is RPC, each part is a parameter or a return value and appears inside a wrapper element within the body. The wrapper element is named identically to the operation name , and its namespace is the value of the namespace attribute. Each message part (parameter) appears under the wrapper, represented by an accessor named identically to the corresponding parameter of the call. Parts are arranged in the same order as the parameters of the call. If the operation style is document, there are no additional wrappers, and the message parts appear directly under the SOAP Body element.

The IDLs of past middleware systems such as DCE, CORBA, and DCOM correspond to the WSDL's what section (we describe all its elements next ). Whereas WSDL portTypes are abstract (not yet bound), IDLs were specific and concrete. This made IDLs' tightly coupled connections very brittle. Additionally, IDLs had no information about how to communicate with their service. They supported only one type of communication protocol, and they provided no information about where to find a service. There was no corollary to WSDL's flexible URL that gives it the property of late binding.

Note

The late bindingness of WSDL is a very important feature. It enables you to have an intermediary "router" that can be a level of indirection between the client and the provider. The client always thinks it is connecting to the router or proxy. By incorporating good load-balancing strategies at this router level, you can build resilience and redundancy into the Web service, both of which enhance security.

Typically, the router stores the WSDL of the provider. At the time of importing the WSDL, it actually modifies the WSDL URL so that the client always calls the URL of the router. The router maintains a table that maps to the "actual" provider address.

What this all means is that not only were middleware systems of the past tightly coupled and brittle, but consequently they were not suitable for cross-organizational boundary communication. This is the area in which Web services excel and what will propel them to become as pervasive as the Web itself. The dark side of this takes us back to our favorite topic: Web services security. When you cross organizational boundaries, security becomes orders of magnitude more important and more challenging.

The other dark aspect of late binding and loosely coupled distributed systems is that things can change somewhere in the system. From a security perspective, that puts a burden on you to be scrupulous about checking the security of all incoming messages. A change somewhere in the distributed system may have been malicious, and the incoming messages may be malformed . Not only do you need to implement strong security technology to combat this problem, but you also need to constantly monitor all your security provisions to make sure you can "see" whether a breach occurs.

WSDL Elements

A WSDL document contains three sections that provide operations, bindings, and services. The document begins with a <definitions> tag and establishes namespaces. The operations section, identified by <message> and <portType> tags, describes what operations are provided. The <binding> tag describes how the operations are invoked. Finally, the <service> tag describes where the services are located. This structure is shown in Figure 2.5.

Figure 2.5. The layout of a WSDL file.

What follows in Listing 2.6 is a real WSDL for a simple add/subtract calculator service from the SalCentral Web site. We break up the example into sections to explain what each section is for.

The entire WSDL definition is bracketed by the <definitions> tag. Initially, the namespaces are defined for this specific WSDL, for the XML Schema used, for SOAP, and for WSDL.

Listing 2.6. The WSDL Definitions Section for SimpleCalculator

Next in Listing 2.7 is the operations section using <message> tags first and then <portType> tags. Messages are grouped in pairs, the first defining the request and the second defining the response. Next, port types identify to whom the message is sent and how. A port type is a collection of operations ”in this case, Add and Subtract operations:

Listing 2.7. The WSDL Operations Section for SimpleCalculator

The second major section of the WSDL file describes how the operations are performed by binding together a port, transport, and the operations earlier in the file as shown next in Listing 2.8:

Listing 2.8. The WSDL Bindings Section for SimpleCalculator

The third and final section of the WSDL file describes where the service resides, giving a specific URL address. In many cases, a Web server running servlets will process an incoming Web service request. In the example in Listing 2.9, the Web server immediately turns this request over to a CGI script.

Listing 2.9. The WSDL Section Defining Where the SimpleCalculator Service Resides

WSDL and SOAP

WSDL specifies the interface definition separately from the implementation definition in the service contract. That is, the what part is separate from the how and where parts.

WSDL defines the structure of the SOAP message. The linkage is strong and direct. The contents of the SOAP payload conform to the input and output messages defined in the WSDL what part. The how of the WSDL defines the way the messages will be packaged in the SOAP envelope, and it defines information that needs to be in the SOAP header. Finally, the binding between SOAP and its transport is defined in the where part of the WSDL.

WSDL Versus XML Schema

An XML Schema is an XML vocabulary for expressing data business rules. Data business rules are constraints. A sample constraint might be as follows: A location must be expressed as a latitude followed by a longitude followed by an uncertainty measure. Furthermore, latitude is a decimal real number between “90 and +90, and longitude is a decimal real number between “180 and +180. Finally, uncertainty must be a non-negative integer whose units are either feet or meters . This entire example can be expressed in an XML Schema.

An XML Schema defines a contract between a service provider and its clients . That sounds amazingly close to the definition of WSDL. Our definition of Web services could almost be met by using an XML Schema, but an XML Schema is not enough.

WSDL contains XML Schemas that describe the data so that both sender and receiver understand the data being exchanged. Beyond what XML Schemas can provide, WSDL also describes the operations and location of the service itself and the binding of the operations to the transport. WSDLs are typically generated by automated tools that start with application metadata that is transformed into XML Schemas and are then merged into the WSDL file.

WSDL and Web Services Security

WSDL can innocently be the biggest security hole in a Web services deployment. Here's why. The development tools place the automatically generated WSDL file in a standard location. If that structure is copied from the staging Web site structure directly into the production Web site structure, the WSDL is now on the exposed Internet in clear form. It is publicly advertising to the outside world the what, how, and where of your entire Web service. Anyone can read it and begin accessing your Web service. If you do not have additional security such as required authentication, outsiders are now happily pulling any and all information your Web service allows. The Web service might provide essentially direct access to your core enterprise applications or databases. This would be bad.

At the very least, organizations must protect the WSDL URL with SSL requiring client authentication. Then no people external to the organization can even read the WSDL file unless you specifically authorize them to do so. Your server will demand a client SSL certificate that identifies who is trying to access the WSDL, giving the server the power to deny anyone not recognized to it.