Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
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
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.
Proxy-based approach
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.
High-Level Architecture
Figure 1: A proxy-based approach to secure Web services
Framework Explained
The proxy Web service uses Web services handlers to intercept XML messages used in Web services. It contains two major components, namely:
- Authentication handler
- Proxy client
Needless to say, the authentication handler is realized by using a Web service handler and the proxy client is the back-end component. The two components are packaged into a single Web service. While the authentication handler authenticates the client, the proxy client invokes the actual Web service.
To start with, the end client sends the request to the Web service proxy along with its credentials. The credentials could be either a clear text password or a digital certificate. In case of basic authentication, the credentials (username and password) need to be sent as HTTP header parameters. In the case of advanced authentication, the end client signs the XML message with his/her digital certificate and sends the signed XML message to the server. Now the client has done its job.
On the server side, the authentication handler acts as an XML interceptor, which receives the XML message and the HTTP header parameters, if any. Depending on the type of authentication mechanism needed, the corresponding implementation is invoked to verify the credentials. By providing many hooks, different kinds of implementations for the authentication could be integrated very easily. The Lightweight Directory Access Protocol (LDAP) server can act as an ACL repository, which stores all the clients’ profiles.
In the process of authenticating the client, the credentials being sent by the clients can be verified against the credentials stored in the ACL repository. If they are found to be matching, the user is authenticated successfully. Otherwise, the authentication process is a failure and the handler will send the failure message to the end client. In the case of successful authentication, the proxy client invokes the actual Web service by constructing a new SOAP message and sending it to the server hosting the actual Web service.
As far as the end client is concerned, he/she gets the response from the proxy Web service and the whole logic of authentication and actual service invocation is abstracted out. The other advantages of this new proxy approach over other products are as follows:
- Lightweight framework
- Low cost
- Easy to integrate
- Quick to deploy
Interaction Diagram
Note: The response flow is not shown in this figure. The actual Web service responds to the proxy client, and the proxy client will send the response back to the end client.
Conclusion
This article has discussed Web services and the security issues involved in using Web services. It also briefed you about the various solutions available and how the proxy-based approach can be very useful for securing Web services.
References
- http://www.Web services.org
- http://ws.apache.org/axis
- http://xml.apache.org/security/index.html
- http://www.w3c.org
About the Authors
Rajesh Devadas holds a Master’s degree in Computer Applications from MK University, India. He has been working as a Technical Lead for Hewlett-Packard, Bangalore with more than 10 years of domain experience in e-commerce, telecom, and mobile. He is currently involved in designing and developing mobile Web services infrastructure and solutions. He can be reached at Rajesh.Devadas@hp.com or rajesh_devadas@hotmail.com.
Ayyappan Gandhirajan holds a Bachelor’s degree in Electronics & Communication Engineering from MK University, India. He has been working as a Senior Software Engineer for Hewlett-Packard, Bangalore with more than five years of industry experience involving Web services and J2EE technologies. He is currently involved in Web services orchestration and developing access controllers for Web services. He can be reached at ayyappan.gandhirajan@hp.com or G_Ayyapparaj@yahoo.com.
