Basic Techniques in Securing Web Services

Secure Connection

The three most widely used and available techniques for the secure connection are

• Firewalls

• SSL

• VPNs

FIREWALLS

A firewall protects a private network from intruders outside the network. A firewall acts as a barrier for information moving into and out of the LAN/WAN. We can provide varied restrictions to different clients based on origin or identity by employing firewalls such as the Microsoft Internet Security and Acceleration (ISA) server. The use of a firewall method is constructive if you can identify which computers should access your Web service. Then, you can implement Internet Protocol Security (IPSec) or firewall rules to restrict access to computers of known IP addresses. But in real time, you may not know the IP address of all the computers. Moreover, any unauthorized user may access the resource by using an IP spoofing technique. IP spoofing is a technique by which an invader simulates the IP of an authorized user and can access the resource. However, a correctly configured firewall is not vulnerable to this.

A Web service is a programmable entity that provides a particular element of functionality, such as application logic, and is accessible to any number of potentially incongruent systems through the use of common data formats and protocols, such as XML and HTTP. In Web services the traffic flows through port 80 and port 443 similar to standard Web site traffic with the help of HTTP. One of the shortcomings in the security of Web services is in the use of HTTP. Of course, HTTP protocol is simple, and, by using it along with XML, we can effortlessly make the application logic accessible to various dissimilar systems and communicate with other applications. But the problem is that HTTP penetrates through the enterprise security firewalls and makes attack and invasion easy to accomplish from outside. Even though firewalls play a vital role in controlling malicious attacks, they cannot examine the SOAP contents to completely prevent the malicious attack from outside. Moreover, firewalls are intended only for network-level security, not for application-level security.

SSL AND HTTPS

SSL has been commonly established on the World Wide Web for authenticated and encrypted communication between clients and servers. At present, SSL along with the Transport Layer Security (TLS) ^[1] is widely used for securing online transactions. SSL offers confidentiality, data integrity, and authentication (server and client authentication). SSL is already employed by many enterprises to guard data across the Internet. SSL protocol was developed by Netscape, and it is a common technique used to secure the TCP/IP communication between HTTP requesters (Web browsers) and HTTP servers (Web servers). SSL employs public key cryptography ^[2] for Internet security. HTTPS secures communication by transmitting HTTP request and response over an SSL connection.

^[1] TLS is SSL 3.0 with proprietary technology support removed, and it is maintained by the Internet Engineering Task Force (IETF). For more information on TLS visit http://www.ietf.org/rfc/rfc2246.txt.

^[2] Public key cryptography is a technique that uses a pair of inversely related asymmetric keys for encryption and decryption. Each pair of keys consists of a public key and a private key. The public key is made public by distributing it widely. The private key is never distributed; it is always kept secret. Data that is encrypted with the public key can be decrypted only with the private key. On the other hand, data encrypted with the private key can be decrypted only with the public key. In 1976 researchers at Stanford University developed public key cryptography.

SSL provides some degree of protection to Web services. It secures the channel in which the transmission of data between the client and server occurs. In SSL the data is encrypted by the client/sender and then sent to the server. The data received is decrypted by the server/recipient and confirmed as being from a truthful sender. SSL provides a secure, reliable connection between authenticated endpoints. The secure channel is initiated with an exchange of messages through an SSL/TLS handshake. The handshake allows the server to authenticate itself to the client, and optionally the client to authenticate itself to the server. Usually, in business SSL sessions, only the server is authenticated. Then, the successive message is encrypted and digitally signed to assure its confidentiality and integrity. Figure 10-1 shows the transmission of data between the Web service client and a Web service over a secure channel.

The limitation of SSL is its low performance. SSL uses certificates and credentials, which drastically slow the overall performance compared to the performance of HTTP. SSL accelerators sometimes can improve the overall performance. Another difficulty in using SSL is that it provides only point-to-point (transport-level) security. That means it provides complete security only between two authenticated entities. If there are more than two entities, and each entity is capable of examining and modifying the data, then SSL doesn't provide end-to-end security.

SSL secures communication only at the transport level, not at the message level. Therefore, data is secure only while traveling over the wire. If it reaches the message level, then the data is not secure. But in Web services data normally is passed through various entities before reaching its final destination. For example, suppose entity A wants to communicate with entity B over a secure channel. If there is an intermediate entity C, say, a gateway, then to route the data to entity B, the gateway may need to know the data. In this scenario SSL doesn't provide end-to-end security. Hence, there is a possibility of data corruption or attack in entity C at the message level while the data is transmitted between entity A and entity B. Therefore, for Web services, SSL can be used only in an environment where data does not route through intermediate application nodes and has no multiple hops. That is, we can use SSL in a tightly coupled Microsoft Windows operating system environment.

NEED FOR END-TO-END SECURITY

SSL/TLS provides security features such as data integrity and data confidentiality, and facilitates point-to-point secure sessions. Similar to SSL/TLS, IPSec ^[3] is also widely employed for the secure sessions.

^[3] IPSec is designed to provide interoperable, high-quality , cryptographically based security for IPv4 and IPv6. It offers security services such as access control, connectionless integrity, data origin authentication, protection against replays (a form of partial sequence integrity), confidentiality (encryption), and limited traffic flow confidentiality. These services are provided at the IP layer, offering protection for IP and/or upper-layer protocols.

Current Web service application topologies comprise a wide range of systems, such as mobile devices, gateways, proxies, load balancers, demilitarized zones (DMZs), and outsourced data centers. Web services have a globally distributed, complex, multidomain and heterogeneous environment, so the SOAP messages must be routed to one or more intermediaries before reaching the final destination, or receiver. The problem is that if the data transmission occurs between the intermediaries beyond the transport layer, then both the data integrity and other security information maybe lost. We need an end-to-end message-level security, and not just point-to-point security, as provided by SSL/TLS. Therefore, for a complete Web service security architecture, we have to incorporate both transport-layer and application-layer end-to-end message-level security mechanisms. Figure 10-2 illustrates the point-to-point and end-to-end configuration.

CONFIGURING SSL IN WINDOWS 2000

To secure XML Web services with SSL in Windows 2000, the following steps have to be done:

• Configure your Web server for SSL: To facilitate SSL support, install an SSL server certificate on the server. If you acquire a server certificate from a third-party certificate authority, then skip to next step.

• Install CA's certificate on the client: If you use your own certificate services, you have to install your CA's certificate on the client as a trusted root certificate authority.

• Modify WSDL from HTTP to HTTPS: The address of your Web service has to start with https instead of http . Revise the Web Services Description Language (WSDL) files accordingly . Specify an https URL as the location of the Web service during the addition of Web reference in Visual Studio .NET. Now we can consume the Web service over SSL.

• Enforcing SSL-only access: If the Web service is intended to accept only SSL requests , then configure the virtual directory as follows .

  1. Right-click the virtual directory where the Web service resides, then click Properties.

  2. Click the Directory Security tab, and then click Edit under Secure Communications.

  3. Click Require secure channel (SSL) and then click OK twice.

VIRTUAL PRIVATE NETWORK

1. A VPN connects multiple networks, wireless users, and other remote users. Thus, VPN is an extension of private networks, such as WAN, and is more efficient than WAN, since it uses the already existing Internet infrastructure.

2. A VPN facilitates a secure connection through which data passes between multiple networks over the Internet.

Authentication and Authorization

Authentication is the process of confirming the identity of a client user/application before permitting the user/application to access a resource. For example, users who request the resources have to submit some set of credentials, such as user ID and password. In return, the user receives a security token from the server. In the Web services world, the security token may be in the form of a cookie placed on the user's browser, a session ID stored on the server, and so on. The simplest method to implement an authentication mechanism for a Web service is to use the authentication features of the HTTP.

Authentication Mechanisms for HTTP

Microsoft IIS version 5.0 supports several authentication mechanisms for HTTP, such as Basic, Digest, Windows Integrated, and Client certificate.

BASIC

In Basic authentication, the user is prompted for a login ID and password. If the user provides a valid Windows account, a connection is established. The main drawback in basic authentication is that Web browsers transmit the collected information in an unencrypted plaintext form to the Web server. By observing communications between networks, one can easily interrupt and decipher these passwords by using publicly available tools. We therefore recommend using HTTPS (i.e., Basic over SSL).

DIGEST

Digest authentication is similar to Basic authentication. The only difference is that it entails a different way of transmitting the authentication credentials. In this method hashing is employed to transmit authentication credentials to the server in a secure manner. One cannot decrypt or decipher the original text from the hash or message digest. A message digest is a unique value derived from the message content. However, this method is not supported in many platforms other than Microsoft Windows. Internet Explorer 5.0 and later browsers support Digest authentication, but other browsers, such as Netscape Navigator, do not support Digest authentication natively.

INTEGRATED WINDOWS AUTHENTICATION

This Integrated Windows authentication method is suitable for intranet scenarios. The user's credentials are transmitted to the server using NT LAN Manager (NTLM), NT Challenge/Response (NTCR), or Kerberos. ^[4] The problem in using Integrated Windows authentication is that it does not work over HTTP proxy connections or other firewalls. IIS authorizes access to the Web service if the credentials submitted by the user match a valid user account. In Integrated Windows authentication it does not initially ask users for a username and password. The current Windows user information on the client computer is utilized for the Integrated Windows authentication. The browser asks the user for a Windows user account if, and only if, there is an occurrence of failure to identify the user during the initial authentication exchange. Figure 10-3 shows the Internet Services Manager settings. To configure this method, check the Integrated Windows authentication box in the Internet Services Manager dialog box, as shown in Figure 10-4.

^[4] Kerberos is a freely available network-authentication protocol developed at the Massachusetts Institute of Technology (MIT). It is an open-source protocol, which uses shared secret key cryptography to authenticate users and provides a means of verifying the identities of principals (e.g., a workstation user or a network server) on an open ( unprotected ) network.

CLIENT CERTIFICATES

In this method, to access the service, clients have to get a client certificate from a mutually trusted third-party organization. Then, certificates are mapped to user accounts, which are used by IIS for authorizing access to the Web service. Client certificates are electronic documents that contain identifying information such as the user data and the organization that issued the certificate.

Another alternative to IIS authentication schemes is the use of a custom mechanism, such as transmitting client credentials through a SOAP header.