Web Services Security Challenges
|
In Chapter 2, we were introduced to the layers of the OSI stack. Table 3-1 shows us how the OSI layers apply to Web Services.
| Layer Number | Layer Name | Web Services Technology |
|---|---|---|
| Layer 7 | Application | HTTP, SMTP, SOAP |
| Layer 6 | Presentation | Encrypted data, Compressed data |
| Layer 5 | Session | POP/25, SSL |
| Layer 4 | Transport | TCP, UDP |
| Layer 3 | Network | IP Packets |
| Layer 2 | Data Link | PPP, 802.11, etc. |
| Layer 1 | Physical | ADSL, ATM, etc. |
Notice that SOAP is in layer 7, together with HTTP and SMTP. However, SOAP travels over HTTP or SMTP. This does not mean that SOAP belongs in a new layer, a layer 8. On the contrary, the seven-layer communications stack still applies for each individual communication from a SOAP requester to a Web Service. However, one SOAP-based communication is not the full story. Web Services security presents three challenges:
-
The challenge of security based on the end user of a Web Service
-
The challenge of maintaining security while routing between multiple Web Services
-
The challenge of abstracting security from the underlying network
Let’s examine each of these challenges.
The Challenge of Security Based on the End User of a Web Service
SOAP is a technology used to enable software to talk to other software much easier than was previously possible. End users (that is, humans) do not make SOAP messages themselves. However, if access to the Web Service is to be decided based on the information about the end user, the Web Service must have access to the information that allows it to make this authorization decision. This information does not have to include the end user’s actual identity. Consider Figure 3-1.
Figure 3-1: Security based on the end user of a Web Service
The end user in Figure 3-1 is accessing a travel Web site and making a reservation. The reservation is made, on the user’s behalf, on a third-party system accessed using SOAP. The end user may have authenticated to the travel Web site, perhaps using a username and password. Because of the successful authentication, the user may have been shown personalized content. Information about the user’s identity, as well as attributes of the end user such as their travel preferences and previous bookings, are known to the Web site. However, in Figure 3-1, we see that the Web Service only has visibility of the travel Web site, not the end user.
How can this information about the end user be conveyed to the Web Service? Session layer or transport layer security between the application server and the Web Service doesn’t convey information about the identity of the end user of the Web Service. It merely conveys information about the application server that is sending the SOAP message. It may be the case that many of the requests to the Web Service originate from that application server.
This challenge is addressed by including security information about the end user in the SOAP message itself. This information may concern the end user’s identity, attributes of the end user, or simply an indication that this user has already been authenticated and/or authorized by the Web server. This information allows the Web Service to make an informed authorization decision.
This scenario is likely to be widespread where many Web Services are used to implement functionality “behind the scenes.” It shouldn’t be the case that the end user has to reauthenticate each time a SOAP request must be sent on their behalf. The challenge of providing this functionality is sometimes called “single sign-on” or “federated trust.”
End-User Access to a Web Service: A Practical Example
This example uses the ASP.NET Web Matrix tool, freely downloadable from http://www .asp.net. ASP.NET Web Matrix in turn requires the .NET Framework to be installed. The .NET Framework can be downloaded from the following URL: http://msdn.microsoft.com/netframework. Please ensure that you download the latest service pack for the .NET Framework.
Simple “Add” and “Subtract” Web Services
When ASP.NET Matrix is opened, it displays the dialog box seen in Figure 3-2.
Figure 3-2: The ASP.NET Add New File page
Enter calculations.asmx in the Filename text box, Calculations in the Class text box, and Example in the Namespace text box. Choose C# as the language. Now click OK. You will be presented with the screen shown in Figure 3-3.
Figure 3-3: ASP.NET development environment
Conveniently, for our example, the code for an example Add Web Service is already provided. Now add a “Subtract” method so that the code listing onscreen is identical to the following code:
<%@ WebService language="C#" %> using System; using System.Web.Services; using System.Xml.Serialization; public class Calculations { [WebMethod] public int Add(int a, int b) { return a + b; } [WebMethod] public int Subtract(int a, int b) { return a - b; } } Click the Save button and then click the Run icon (the right-facing triangle on the toolbar). You will be prompted with the dialog box seen in Figure 3-4.
Figure 3-4: The ASP.NET Web Services deployment dialog box
Click the Start button to start the ASP.NET local Web server. Now open a Web browser and navigate to http://localhost:8080/calculations.asmx . A Web form is automatically created in order to pass data to the calculation Web Services. In order to see the WDSL descriptors for the Web Service, navigate to http://localhost:8080/calculations.asmx?WDSL.
From the main Calculations Web Service page, click the Add link. The resulting page shows a Web form that can be used to submit data to the Web Service, and examples of SOAP messages that can be targeted to the Web Service.
It is important to note the distinction between the user calling the Web Service directly, using the form, and the scenario where SOAP is sent on the user’s behalf. This distinction is shown in Figure 3-5.
Figure 3-5: Direct vs. indirect access to a Web Service
When the data from the form is submitted to the Web Service, the user’s browser is making a direct connection to the Web Service, using HTTP GET or HTTP POST. SSL, or cookies can be used to secure the connection between the Web Service and the user’s browser. However, when SOAP is used—meaning that one of the example SOAP messages is submitted to the Web Service—the user is one step away from the communication. The application sending the SOAP message on the user’s behalf may use cookies or SSL, but that would only secure the connection between the application and the Web Service. If the user has connected to a Web site that uses the calculation Web Service on their behalf, then the Web Service will only have visibility of the Web site that is sending the SOAP message, not of the end user on whose behalf the message is being sent.
The problem is that there are two security contexts in play. These are spelled out in Figure 3-6.
Figure 3-6: Multiple security contexts
In our trivial calculation example, it may not seem important who is running the Web Service. But imagine that the end user is a currency dealer who connects to a local portal in order to execute a trade. If a Web Service is run on that dealer’s behalf, the provider of the Web Service must know not only what portal is sending the SOAP request to it, but who the dealer is. The solution to this problem, as we will see, is to include information about the end user in the SOAP message itself.
The Challenge of Maintaining Security While Routing Between Multiple Web Services
Although SOAP routing is not in the scope of SOAP 1.1 or SOAP 1.2, it has been proposed as part of Microsoft’s GXA (Global XML Web Services Architecture). WS-Routing provides a means for SOAP messages to route between multiple Web Services. WS-Routing defines how to insert routing information into the header of a SOAP message. This routing information can be thought of as equivalent to routing tables that operate at lower layers of the OSI stack for routing IP packets.
WS-Routing means that one SOAP message may traverse multiple SOAP “hops” between the originator and the endpoint. The systems that implement these hops may have nothing in common apart from the ability to parse and route a SOAP message.
The following code listing is an example of a SOAP message that uses WS-Routing in order to route between Web Services. It routes from the originator, via an intermediary, to an endpoint. It is targeted at the Calc Web Service, familiar from the previous example in this chapter.
<?xml version="1.0" encoding="UTF-8"?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <SOAP-ENV:Header> <h:path xmlns:h="http://schemas.xmlsoap.org/rp/" SOAP-ENV:actor="http://schemas.xmlsoap.org/soap/actor/next" SOAP-ENV:mustUnderstand="1"> <rp:action xmlns:rp="http://schemas.xmlsoap.org/rp/"> Addition </rp:action> <rp:to xmlns:rp="http://schemas.xmlsoap.org/rp/"> http://www.example.com/Calc </rp:to> <rp:fwd xmlns:rp="http://schemas.xmlsoap.org/rp/"> <rp:via>http://wwww.intermediary.com/webservice</rp:via> </rp:fwd> <rp:rev xmlns:rp="http://schemas.xmlsoap.org/rp/"> <rp:via/> </rp:rev> <rp:from xmlns:rp="http://schemas.xmlsoap.org/rp/"> originator@example.com </rp:from> <rp:id xmlns:rp="http://schemas.xmlsoap.org/rp/"> uuid:EC823E93-BE2B-F9DC-8BB7-CD54B16C6EC1 </rp:id> </h:path> </SOAP-ENV:Header> <SOAP-ENV:Body> <SOAPSDK1:Add xmlns:SOAPSDK1="http://tempuri.org/message/"> <A>1</A><B>2</B> </SOAPSDK1:Add> </SOAP-ENV:Body> </SOAP-ENV:Envelope>
Figure 3-7 illustrates how this routing scenario involves more than one security context.
Figure 3-7: Multiple Security Contents when SOAP is routed
SOAP routing does not have to depend on routing information in the SOAP message itself. Routing can be performed for a number of reasons, including scaling a Web Services infrastructure between multiple SOAP servers, bridging between two different networking protocols, or transforming message content from one format to another. All of these scenarios extend the security context beyond a single SOAP request/response.
When routing between Web Services, the requirement for confidentiality can apply from the originator through to the final SOAP endpoint. It may be a requirement that information be kept secret from SOAP intermediaries. There may be a chance that intermediaries may disclose the information either deliberately or through leaving “gaps” between one transport-level security session and the next. While the data is decrypted, it is vulnerable. This is the same problem that plagued the first release of the Wireless Access Protocol (WAP), in which data was decrypted in between the wireless encryption session and encryption on the fixed wire. This so-called “WAP gap” caused a loss of confidence in WAP security and was addressed in later releases of the WAP specification. Implementing encryption only at the transport level makes a “SOAP gap.”
It is often noted that most security breaches happen not while data is in transit, but while data is in storage. This is the principle of least resistance—attempting to decrypt eavesdropped encrypted data from an SSL session is much more difficult than simply testing if a Web site maintainer has remembered to block direct access to the database where the credit card numbers are stored. If decrypted data is stolen from a database, the consequences are no less dramatic. Once data has reached its final destination, it must be stored in a secure state. Confidentiality for a SOAP transaction should not involve simply chaining instances of confidentiality together, since “SOAP gaps” of unencrypted data are available between each decryption and encryption.
The Challenge of Abstracting Security from the Underlying Network
As we saw in Chapter 1, the term “Web” Services is misleading. “Services” is somewhat redeemable since it indicates a services-oriented architecture (SOA). However “Web” points squarely at the World Wide Web. However, Web Services is not reliant on HTTP. “Net Services” would have been a better term, but it is too late to change the name now. Just as Web Services is not reliant on the Web, Web Services security cannot rely on Web security. This does not mean that Web security can be ignored. We’ll see later in this chapter that Web server security can be the “soft underbelly” of an HTTP-based SOAP service and may well afford the path of least resistance to an attacker.
SSL is the obvious choice for confidentiality and authentication (one-way or two-way) for the single connection between a SOAP requester and a Web Service over HTTP. First-generation Web Services are almost unanimously using HTTP, so for the implementer, the reasons to use SSL are compelling. However, second-generation Web Services are likely to move beyond HTTP to reliable messaging frameworks such as HTTPR and SonicXQ, and peer-to-peer technologies such as Jabber.
SSL: A Pragmatic Solution
The challenge of HTTP independence is one that faces standards groups as they are generating Web Services security specifications. A more mundane challenge faces the architect charged with implementing Web Services for their organization: to get secure services up and running as soon as possible. SSL provides for confidentiality between the SOAP requester and the Web Service itself, as well as authentication. If this is all that is required, with no possibility that end-user security or SOAP routing will be introduced to the solution in the future, then this is a pragmatic solution. Chapter 2 explained that it is the high-level principles of security that must be implemented, and just because SOAP is used, it doesn’t follow that SOAP security must be used. SSL is available in all Web servers, and with the vast majority of first-generation Web Services using HTTP, it is a useful and pragmatic solution.
|
