Web Services Defined
Web services are the small software components that are exposed over Internet. Publishing as Web services makes the software applications more reusable and shared by a lot more users. Web services enable business partnering and thereby generate a great way of revenue streaming for the companies. It also helps in reducing the development, integration, and maintenance cost of the software application.
SOAP (Simple Object Access Protocol) is the communication protocol that helps in transporting the XML messages between the client and server. SOAP is nothing but XML over HTTP. When the Web service client makes a request, the SOAP client API constructs a corresponding XML message containing the remote method name and value for its parameters and sends the XML message over HTTP protocol to the server hosting the Web services. The server receives the XML message, executes the business logic (may be written in Java), and sends the response back to the client.
Issues with Using Web Services
When we talk about the benefits of Web services, we can't overlook the few issues in using Web services, too. The primary issue is security. The other Web applications, such as Java Servlets, are being accessed via HTTP browser. The user-specific information can be stored in the HTTP session and used for users' session tracking. A fine example for this is the shopping cart application.
But, because Web services are being invoked by the standalone client applications, the server could not have any idea about the user who is actually making the request. This would pose a major problem that any unauthorized user may consume our Web services and we can't have any control on this. Another serious problem is the tampering of XML messages while they are transmitted over wire.
Possible Solutions Explained
Secure sockets layer
It's now very clear that there needs a security solution to control the access to these Web services, deployed at the service providers' site. Secure Sockets Layer (SSL) based communication may be useful to protect the Web services. SSL allows two applications (i.e., server and client) over network to authenticate each other's identity by exchanging their digital certificates and then talk to each other by sending encrypted messages. Digital certificates and encryptions make the Web services invocation very secure.
But SSL operates in the transport level and it can secure only the connection between the client and server. If there is an intermediary between the server and client, the intermediary gets the message in plain text and if it forwards the message to any other machine, the destination machine would not be able to guess who the original sender was. The other problem with SSL is that it encrypts whole message and it can't be used for partial encryption of messages.
Message-level security could be the best bet. It's comprised of all the benefits of SSL and is also very flexible. The part or whole of the actual SOAP message is digitally signed and sent to the server. The server verifies the signature to check whether the message is tampered. If the message is not tampered and sent by the valid user, it executes the business logic and sends the result of execution back to the client. In this process, even if the SOAP message crosses many intermediaries, every machine would be able to recognize the actual sender.
It's good that a message-level security mechanism is very useful in securing the Web services. But, how would you protect the Web services, which have already been deployed, tested, and running in the production server? Modification to these Web services may not be feasible because it will have a serious impact. To address this, a new approach is required, one that could capitalize on the message-level security mechanism and help in securing not only the new Web services, but also the already running Web services without being disturbed.
This new approach introduces the proxy-based lightweight framework for providing the secure access to the Web services being requested by the clients. The basic idea is to deploy a proxy Web service that receives the request from the end client on behalf of the actual Web service. The proxy service authenticates the end client by validating the client's credentials, which he/she had sent along with the Web service request. If the client is authenticated successfully, he/she will be given access to the requested service.
The advantages of this approach are as follows:
- It is based on message-level security.
- It does not only authenticate the user, but also verifies the message integrity.
- It doesn't disturb the actual Web service, which may be running on the production server.
- It acts like a plug-in; it can be removed and replaced with any other solution at any point in time.
- It hides the actual Web service; the process is abstracted from the client. The client would not know that his/her request has been intercepted and processed by a proxy.
- Integrating new handlers, such as Auditing and Notification, is very easy. Whereas an auditing handler is for maintaining the service access information, a notification handler could be used for sending e-mails to the service providers in case of any problem in accessing the service.
Someone might now want to raise a question about the performance of the proxy approach. Because of the introduction of a proxy in the communication path of end service, the invocation time will be a little more. However, the performance figures are more acceptable.
Figure 1: A proxy-based approach to secure Web services