The Foundations of Web Services Security
The objective of this article is to detail the various Web services security models prevailing in today's IT world. This article is targeted towards the developer community working to secure their Web services. This would be a starting point for developers to know about the various standards available in the market for securing a Web service and how the standards are related.
A Web service is a self descriptive, reusable, and loosely coupled software component defined using WSDL, registered using UDDI, and invoked using SOAP that is exposed over the Internet. It is a real interoperable technology that makes any two applications communicate with each other using a common protocol; for example, XML. This behavior makes Web services play a major role in enterprise application integrations and building business applications based on Service Oriented Architecture.
The Need to Secure Web Services
It's been some time since the emergence of Web services in the IT paradigm. More and more enterprises are developing and deploying Web services for their business models in the production environment. As the usage of Web services increases, the need to standardize the way to secure the Web services also increases. Today, securing the Web service is a big concern for enterprises. Web services can be dynamically discovered and consumed by posting XML messages over a standard protocol such as HTTP. It is obvious that HTTP is vulnerable to many security attacks. The potential security problems that Web services may face are:
- An unauthenticated person might try to consume the services
- An authenticated person without sufficient permissions might try to access services
- The XML message might be modified by hackers and the recipient might get the message in altered form
- The sender might try to non-repudiate
Consider the following enterprise bank service exposed as a SOAP service and the various threats on this service when exposed on the Internet.
A Real-Time Scenario
Enterprise X, as a part of providing value and adding services to the customers, would like to expose some of its banking capabilities to its consumers through the Internet as Web services. The banking service provides the functionality to transfer funds between accounts. Valid users can transfer funds from one account to another. This functionality of the enterprise is exposed as a Web service. Other possible business functionalities that can be exposed by this service would be checkBalance, viewLastTransaction, and printStatementforMonth.
The following diagram shows the various client invocations to the banking service when deployed as a SOAP service.
Now, consider various scenarios in which the banking service gets invoked.
Scenario 1: Client A invokes the "transferFund" operation of the banking service. Because this is a valid client, the invocation goes through and the client A is able to transfer funds between accounts.
Scenario 2: Client B, who is authorized to invoke the other operations and is NOT authorized to access the transferFund operation, can also invoke the transferFund operation because there is no security imposed to restrict this access in the server side.
Scenario 3: Client C, who is NOT an authorized client for invoking any of the operations provided by the banking service, can also access all the operations because there is no security imposed to restrict this access in the server side.
Scenario 4: An unknown client (hacker) can trap the SOAP message between client A and the banking service and then can tamper with the SOAP message and send it to the server. This would be the most critical threat to the enterprise running the banking service.
From the above scenarios, you can see that Scenarios 2 through 4 should be considered security threats for any enterprise providing their business capabilities as a Web service. This shows the need for a security model to be followed in the enterprise to make the service more reliable and secure.