In-Depth

Architecting Security for Web Services

Ponder the security challenges posed by Web services, how to address them with security architecture, and what security architecture can offer going forward when XML traverses firewalls.

• By Mark O'Neill
• 08/01/2003

Web services are a technology that promises to revolutionize systems integration by applying the same XML-based technologies that drove the Web revolution. However, despite this grand promise, Web services technologies are often misunderstood. One of the main culprits is the name itself. "Web services" implies "Services offered on the World Wide Web." However, the fact is that the first wave of Web services is being rolled out behind the firewall, linking back-office systems together. Most organizations have no intention of sending XML across the firewall in the near future. Does this factor mean that security is not an issue? Unfortunately, no. Let's take a look at the security challenges posed by Web services, how they can be addressed using security architecture today, and how this same security architecture can extend to the future when XML traverses firewalls.

First, let's take a step back. What are Web services, and why do they present security challenges? Web services are a set of technologies that allow applications to communicate with each other using XML. The Simple Object Access Protocol (SOAP) specification describes how these XML messages are sent between applications by applying an envelope to the XML data. SOAP was originally intended as a way to send function calls between objects, hence the original spelled out version of the acronym. However, as of SOAP 1.2, "SOAP" no longer stands for anything, which is a consequence of the fact that its use has expanded far beyond communication between software objects. SOAP is increasingly finding a niche as a messaging system between applications, that is, e-mail for applications.

SOAP messages are generally sent over HTTP, the standard Web protocol. For the past five years, Secure Sockets Layer (SSL) has been deployed widely as a security technology for HTTP. SSL provides confidentiality, through encryption, and authentication, using X.509 digital certificates, for HTTP traffic. In addition, many authorization tools exist to control access to Web sites, and to manage single sign-on sessions across Web sites. Over the years, Web servers and Web applications have had many well-documented security problems, and a plethora of best practice information is available that describes how to patch and remedy these problems. In view of all of this information, are existing security solutions such as SSL, Web access control tools, and frequent patching good enough to secure Web services? The answer is no. Let's look at the three security reasons why they aren't.

Three Security Issues
Why is SSL not enough? Although SOAP is often sent over HTTP ("bound to HTTP" in the jargon), it does not necessarily have to be. SOAP is independent of the underlying communications layers. SOAP messages can also be sent over e-mail—that is, Simple Mail Transfer Protocol (SMTP), or FTP—just as easily. In fact, since HTTP is stateless and not entirely reliable, many organizations have no intention of using it to transport SOAP messages.

A single SOAP message can traverse a number of different transports in the context of one transaction—for example, using HTTP for the first leg, then SMTP for the next leg, and so on. SSL, as we've seen, provides confidentiality and authentication for a single point-to-point HTTP session, but it doesn't provide an audit trail that guarantees that the session occurred.

The solution to this problem is to apply the security to the SOAP message itself, rather than relying on the transport on which the SOAP message is sent. This solution ensures that even if the SOAP message is sent over an insecure transport, or if it traverses a number of legs through untrusted servers, it remains secure. Remember, we likened SOAP to e-mail between applications; the analogy with e-mail continues to hold here. If an e-mail message is being sent across the Internet, it isn't sufficient to simply encrypt the links between e-mail servers. The e-mail message itself must be encrypted. So it is with SOAP messages. The World Wide Web Consortium (W3C) and the Organization for the Advancement of Structured Information Standards (OASIS) have developed a number of new specifications for this purpose. XML Signature and XML Encryption describe how integrity and confidentiality are enforced for XML documents, while WS-Security applies these XML security technologies to SOAP messages.

Who is accessing this Web service? SOAP requests are generated by applications, not people. However, security decisions often depend on the identity of people. Picture a situation where an insurance broker authenticates with a password to a claims portal, and then fills out a Web form with requests claims information (see Figure 1). SOAP messages are sent from the claims portal to a number of insurers on the broker's behalf. The insurers use transport layer security to authenticate the sender of the SOAP request, that is, the claims portal. However, what if the insurer requires the ability to see who the broker is, or attribute information about the broker? The security context must extend from the end user, who authenticates with a password, to a Web service, which is run on their behalf using SOAP messages. This security challenge is met by inserting security information about the end user inside the SOAP message. This information concerns the authentication status of the broker, what actions they are authorized to perform, and other attributes of the broker that may be used to make an access-control decision.

The Security Assertion Markup Language (SAML) specification from OASIS describes how this information is formatted into XML as assertions about the end user, and the WS-Security group in OASIS is defining how these assertions are placed into SOAP messages. Organizations already have directories and user profiles, and will wish to reuse these to secure access to Web services.

Keeping out the bad guys. Technologies such as XML Signature, XML Encryption, WS-Security, and SAML can be seen as the positive aspect of Web services security, new specifications and protocols that extend current security techniques to the XML world. By contrast, protecting against new types of hacker attacks is the negative aspect. Web services, as well as Web services security tools, are useless if the user is required to play by the rules. A sophisticated authorization system using SAML and WS-Security is useless if the Web service on which it runs can be disabled by a CodeRed attack.

Most of the new threats against Web services are in fact old threats such as buffer overflows that exploit programming errors and carelessness in configuration, but the avenue of attack—SOAP—is new. Firewalls have traditionally protected against vulnerabilities at the lower layers of the Open Source Initiative (OSI) stack. Firewall functionality has progressively moved up the OSI stack to reach the application layer. For firewalls, the ability to be SOAP intelligent means filtering SOAP messages based on the content and format of the messages—by validating them against XML Schema definitions and against XPath statements.

What Can Firewalls Do?
Many firewalls have been configured to allow only Web (HTTP, SSL) and e-mail (POP, SMTP) traffic to pass. Other TCP/IP ports, and other protocols, are routinely blocked. It has become standard practice to tunnel other applications through the Web ports (80 for HTTP, 443 for SSL), disguised effectively as normal Web traffic. This camouflage is generally not done for malicious reasons, but rather for pragmatic reasons, since all other ports are blocked.

We've seen that SOAP is very frequently bound to HTTP. When a firewall examines a SOAP request received over HTTP, it might conclude that it is valid HTTP traffic and let it pass. Firewalls tend to be all or nothing when it comes to SOAP, and this is a bad thing. A SOAP-level firewall should be capable of: 1) identifying if the incoming SOAP request is targeted at a Web service that is intended to be available to the requester, and 2) identifying if the content of the incoming SOAP message is valid for the target Web service. This second capability is analogous to what happens at the network layer, where IP packet contents are examined to ensure that they are appropriate for the network service that is being accessed. However, at the application layer this procedure requires precise knowledge of the format and content of XML data that the Web service expects. XML Schema and Web Services Description Language (WSDL) provide this precise information.

Web services present details of their interface in WSDL files, which effectively say, "here is a description of the requests that I expect from you," inviting a hacker to send it inappropriate data to see what happens. A WSDL file may contain this line:

<xsd:element name=
   "tickerSymbol" type="string"/>

This line indicates that one of the parameters expected by the Web service is a string, called tickerSymbol. The options a speculative attack on this Web service would include sending it a number instead of a string, or sending it a very large string designed to overload the Web service. Performing "sanity checks" on incoming data directed to Web services is, therefore, important. Such a check may take the form of checking SOAP parameters against an XML Schema.

Architectural Options
There are three broad architectural options for Web services security: XML Gateway, Interceptor, and custom coded. XML Gateways—sometimes called XML firewalls or XML proxies—are software packages or appliances that filter XML traffic upstream of a Web service and block unauthorized traffic before it can reach a protected Web service (see Figure 2). An XML Gateway enforces access control rules by processing security tokens contained within incoming SOAP messages, and by ensuring that the XML format and content is appropriate for the target. It may use SAML to establish the authentication status of an end user or to request attribute information, which is used to make an access-control decision. It is important that XML Gateways contain security adapters to existing security technology such as LDAP directories, traditional firewalls, and PKI. Otherwise, the overhead of rekeying rules and user profiles into an XML Gateway would be prohibitive. As much as possible, an XML Gateway should reuse security infrastructure that has preconfigured users, groups, and roles.

A single XML Gateway can protect many Web services platforms. An XML Gateway does not have to share an operating system with the target Web service, because they are on separate host machines. This separation means that a Linux-based XML Gateway appliance can protect a mixture of .Net-based and Java 2 Platform, Enterprise Edition (J2EE)-based Web services. XML Gateways often perform transformation functionality as well as security. In the XML world, this feature amounts to implementing XSLT.

An alternative architectural option is to deploy Interceptors on Web services platforms. These lightweight Interceptors make use of platform-specific hooks such as ISAPI Filters, JAX-RPC handlers, or Apache Axis handlers. The Interceptor (sometimes called an "agent") then communicates with a centralized XML security server, which performs the processing of security rules (see Figure 3). This architecture puts the security enforcement closer to the Web services application, when compared with the XML Gateway option. It also centralizes security processing just like in the XML Gateway scenario, meaning that the Web services application does not get bogged down with processor-intensive functionality such as cryptography. Also, like the XML Gateway architecture, the Interceptor architecture provides a central point of management and reporting for SOAP traffic. The Interceptor architecture differs from the Gateway architecture security in that security is enforced at the Web service end point itself, rather than requiring XML traffic to travel through an infrastructural device to be secured.

The third option is to write security code into the Web service itself. The .Net Common Language Runtime (CLR) includes implementations of XML Signature, XML Encryption, and WS-Security. This functionality is available to programmers writing .Net-hosted Web services. Similarly, the J2EE environment contains security functionality that is available to developers. The arguments for and against custom-coding are the familiar "build or buy" trade-offs. Whereas the Gateway and Interceptor models provide centralized management and reporting, with the ability to make global changes for multiple Web services, this functionality must be custom-built if platform-specific solutions are written. Of course, a write-your-own solution avoids software license fees and may make sense for organizations that have a large IT staff.

Whatever solution is chosen, it's important that it is not limited to first-generation, inside-the-enterprise Web services and can also be applied to B2B Web services when the appropriate time comes. Inside-the-enterprise deployments may be useful for learning about Web services, but if a different security solution is to be used for B2B Web services, then the learning is in vain. Web services present novel security issues, but new industry standards and new XML security products are addressing these issues. There are architectural choices to be made when rolling out XML security, and making these decisions sooner rather than later is important.