Chapter 10: Web Service Security

Security Considerations

Evaluating the amount and focus of security you need is a process that you must consider for any project, not only for a Web Services project. The higher the security, especially with encryption, the greater impact on processing power and memory on the server. This section covers many aspects you need to consider for security purposes.

The Firewall

A firewall is a piece of network hardware or software that regulates the ports and protocols a server accepts or denies. This hardware often sits wherever Internet access comes into a corporation through a T1 line, DSL connection, or some other connection to a provider. It usually allows incoming and outgoing HTTP, telnet, and FTP requests on standard ports; it also determines which internal servers are available to the outside world. Figure 10.1 shows a firewall routing request based on its policies. Notice the role the proxy server plays in these requests. The firewall server allows incoming HTTP and allows outgoing HTTP, telnet, FTP, and nothing else. The proxy server examines each HTTP request, including a Web Service request, and ensures that the request accesses an approved site.

Figure 10.1: A firewall and proxy server working together to protect and monitor the network inside a corporation.

Note

Proxy servers have many more uses, such as caching.

Servers that are often involved in internal projects are not available to consumers or hackers from the Internet. Thus, you can relax your concerns about security. This also means your project is probably free from someone looking at your SOAP messages through a proxy server. A proxy server exists near the corporation’s firewall (not necessarily physically next to it) and ensures that employees are only viewing legitimate Web sites, which include viewing Web Service requests and responses.

There are two layers of security here. Protection from the outside world and not going through a proxy. This doesn’t mean that you can’t have internal malicious users access your system, but it does mean that you have greater control over these individuals when they do something inappropriate.

The Network

By using network hardware and configuration, you can limit and control access. Within an organization it may be possible to put the application and its consumers within their own subnet, where only those users have access to the application through the subnet, but are still able to communicate with the rest of the network. This requires that your application be internal where you have control over the network setup. Figure 10.2 shows a subnet regulating access to a Web Services application. The switch allows traffic out to the rest of the network, but denies access to anything within the subnet.

Figure 10.2: Using a subnet to control access to a Web Services implementation.

The same concept can be applied to external customers with the configuration of the Web server controlling your Web Services. Web servers allow you to determine which Internet Protocol (IP) addresses and domains can access your site. Combining this with configuring the network, you should end up with reasonable security.

This only works, however, if your application is for a unique group of users. You also need to be concerned about Dynamic IP addresses. In this case, users may have a different IP address each time they connect to your service. This is especially true if your user comes through a dial-up Internet Service Provider (ISP) rather than through a corporate firewall, but it often happens with DSL and cable too. These are definitely things to consider when trying to use a network or Web server configuration to control access to your services.

Security Focus

The focus of the security you need to implement depends on your application. If you’re providing a subscription to a Stock Quote service, you want to ensure that your user transmits some sort of credentials to ensure he is a paying user, but the information, such as a value of a stock, is not confidential information. So your focus in this case is on the identity of the user rather than the data.

In another case, you want to ensure that the user identity and the information transmitted are both protected. This is especially true when dealing with credit card information. Remember that you transmit text-based information in an XML file, and thus someone could easily intercept a SOAP document and determine what the information is, as illustrated in the following example.

    Content-Type: text/xml;     charset=utf-8 Content-Length: 461     SOAPAction: ""     <?xml version='1.0' encoding='UTF-8'?>     <SOAP-ENV:Envelope xmlns:SOAP-               ENV="http://schemas.xmlsoap.org/soap/envelope/"                  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"                  xmlns:xsd="http://www.w3.org/2001/XMLSchema">      <SOAP-ENV:Body>        <ns1:purchaseBooks xmlns:ns1="purchasebooks"             SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">             <CreditCard xsi:type="xsd:string">4790-0911-0000-                 0000</CreditCard>             <Expires xsi:type="xsd:string">10-05</Expires>             <OrderId xsi:type="xsd:int">32111</OrderId>        </ns1:puchaseBooks>     </SOAP-ENV:Body>     </SOAP-ENV:Envelope> 

One of the benefits of XML for hackers is that it is self-describing. In other words, when using XML not only do you provide the information in an easy-to-read format but also you insert tags that tell the hackers what the data is! In a case like this, you want to ensure that the data is encrypted and that you send this information to the proper person. Thus, identity and data need to be protected in this example.

When dealing with information such as stock quotes or weather, your security focus centers on identifying the individual. In other cases you may want to protect the data from prying eyes with some sort of encryption, especially with credit card or banking information. You also want to be sure that the identity of the consumer is confirmed.

Hardware and Software Availability

Security often adds to the load on a server, whether it is authentication, Secure Socket Layer, or another form of security. Security that requires encryption and decryption tends to place heavy loads on servers. Therefore, you need to either prepare your system or purchase another system to handle security.

Beyond hardware, you need to ensure that your Web server or other software handles the security that you need. For example, the version of IIS on Windows 2000 Pro does not handle SSL, so if you were using that software, you would need to consider upgrading your system to one that handles SSL properly. This can be done by upgrading to a server version of Windows such as Windows 2000 server or Windows XP server.

If your budget doesn’t allow for the purchase of a new system or systems, you need to consider a security option that fits within your current system. Ensuring that your security needs fit your software and hardware requirements is an important consideration.