Security in Web Services, What and Why

Archived Content
This article is provided for historical perspective only, and may not reflect current conditions. Please refer to relevant product page for more up-to-date product information and resources.
  • By Malinda Kaushalye
  • 10 Dec, 2007

Table of Contents


Web Services

Web services are becoming as a fine solution for distributed systems development. During this process a number of technologies are proposed and developed to implement this finest find. And there are several protocols defined on top of the eXtensible Markup Language (XML). One such protocol is SOAP, that enables, programs dispersed over the Internet to communicate with one another. SOAP defines certain fields in XML format. Communication among Web services could occur independent of human interaction and can be regarded as an important step towards the future of computing, in which, entities are envisioned consuming services without knowing their implementation details. This is possible, as long as a given Web service follows protocols. Interactions among service consumers and providers is expected to be much more than the traditional interaction that has been between humans and web browsers.

In addition to SOAP, other protocols such as WSDL and UDDI also plays important roles. WSDL stands for Web Services Description Language and UDDI stands for Universal Description Discovery and Integration. The former describes different types of Web services a hosting party offers and the latter acts as a registry for services. When a software component needs to consume a web service, it will first look in the UDDI registry to pick up the correct WSDL and will communicate with the service provider, using SOAP. As long as both systems communicate with SOAP and XML, their underlying implementation details become irrelevant.

Image 1: Web Services Model

But hey, wait a second! Can we always trust those who attempts to  communicate with our web services? The world is not always as nice and flowery as we sometimes wish it was. Neither can we expect software to be that way. If your business tunnels millions of dollars to bank accounts every day, then it cannot be left to be paralyzed for days.

Can we ever guarantee, that information we keep in our systems are only accessible to those who are authorized to do so? Can we guarantee privacy with such a loosely coupled modules as in a services oriented architecture? And this is the reason why we need to discuss the topic of security when we deal with Web services.


Information Security

Before we look at security for Web Services, it is important to understand general security requirements applicable to all information systems. Information security can be categorized under six major topics:

  • Authentication: Is the process of identifying an entity as opposed to what/who they claimed to be. Commonly used methods for authotication are user name/password pairs, smart cards and mechanisms based on Public Key Infrastructure.
  • Authorization: Ensures the level of access for authenticated users. In other words, authorization ensures different levels of to access levels for different claiming entities. Access control lists are being used to fulfill this requirement.
  • Confidentiality: Data held within a system are kept protected and made available only to deserving parties. Confidentiality applied during storage and in transit. Encryption methods are used to ensure information confidentiality.
  • Integrity: Ensures that information is not altered at any point within a system. Alterations can be intentional or unintentional. Similar to confidentiality, this can occur during storage or transit. Digital signatures are a used by many to ensure high integrity of data being transmitted.
  • Non repudiation: In digital security, non-repudiation means that it can be verified the sender and the recipient are in fact, the parties who claimed to send or received the message. This ensures that a contract cannot be denied at a latter by either of the parties involved. Digital signatures are used for this purpose together with public Key Infrastructure.
  • Availability: Ensures uninterrupted service availability for all authorized users. Many mechanisms are used to ensure high availability including thwarting of DOS attacks.

Web Services' Security

Web Services security, or to be more precise, SOAP message security, identifies and provides solutions for general computer security threats as well as threats unique to Web services. There are several bodies working on Web services security standards such as W3C (World Wide Web Consortium) and OASIS (Organization for the Advancement of Structured Information Standards). Before WS-Security entered main play, W3C developed standards for XML digital signatures and encryption while OASIS reviewed a number of Web services standards including SOAP and XML.

A major step was taken in April 2002, when Microsoft, Verisign and IBM released the WS-Security specification. This provided the foundation for security in Web services. Later, this specification was accepted by OASIS and became the basis for many other WS-Security specifications developed afterwards. If not for these efforts, we would have ended up with temporary workarounds for securing Web services that would've seriously hindered the development of Web services at an enterprise level.


Threats on Web Services

Many threats that are common to distributed systems are common to Web services as well. Additionally, there are a few specific threats associated with the Web services processing model. Thus, unique security measures need to be taken to thwart these attacks. Here's why:

  1. SOAP messages bound to HTTP or SMTP can be easily passed through firewalls. Contents in these messages may contain malicious code that could cause a Web service to behave in an unintentional manner. Also, un-published services could compromise sensitive data to unauthorized parties.
  2. Since Web services are intended to be used by other software programs, it is less likely that Web service related operations receive human scrutiny. This is good ground for human attackers to try out their skills.
  3. Public disclosure through UDDI and WSDL makes it easier for attackers to discover potential targets.
  4. SOAP, which is the protocol for Web services, does not provide verification on the origins of a SOAP message.
  5. SOAP does not provide a mechanism to ensure the integrity or confidentiality of a message.

Apart from the above list of threats specific to Web services, common threats listed below are also applicable:

  1. Message replays : An attacker may re-play an entire message or a part of a SOAP message.
  2. Man in the middle attack : An attacker may view and modify a SOAP message without the knowledge of either sender or the receiver.
  3. Identity spoofing : An attempt to construct credentials that seems to be valid but not.
  4. Denial of Service (DOS) attacks : An attempt to make a system expend its resources so that valid requests cannot access a service.
  5. Message alteration : An attempt to alter a message compromising its integrity.
  6. Confidentiality issues : Access to confidential information within a message by unauthorized parties.


Limitations in Conventional Mechanisms

SOAP messages can be easily protected using Secure Socket Layer (SSL) or Transport Layer Security (TLS). SSL provides confidentiality and integrity for data streams. Thus, it guarantees secure delivery of data between a client application and a server. Still, there are few limitations:

  1. SSL secures messages on transit, which we call point-to-point security. But, with SOAP, there could be multiple intermediaries participating through the transit. These intermediates might want to add certain headers to a SOAP message, or read certain parts of the SOAP message and this cannot be done with SSL.
  2. With web services we need a message to be protected everywhere between the client application and the service provider - not just at the client or the server machine. A SOAP message needs to be still protected, even after delivery.
  3. Non-repudiation cannot be achieved with SSL. A message delivered can still be denied by the receving party at a latter stage.
  4. SSL cannot provide confidentiality/integrity for a portion of a message (protect only a single XML element of a SOAP document). It encrypts or signs the entire stream.
  5. SSL doesn't provide security for a message inbetween a Web server and a Web service. Confidential data can be exposed during this part of a message delivery.



Image 2: Difference between Transport-Layer and Message-Level Security

Web Services' Security Standards

Due to limitations mentioned earlier, several standards have been developed to secure Web services. Rather than having application specific, ad-hoc workarounds, it was necessary to find a common solution that could be used at the enterprise level.

  • XML Encryption : A W3C recommendation. Provides syntax and processing rules for encrypting an XML document. This provides the confidentiality to selected portions of a message, keeping other parts accessible for intermediaries.
  • XML Signature : A W3C recommendation. Provides syntax and processing rules for signing an XML document. Different parts of a document can be signed to ensure integrity and to provide authentication.
  • XKMS : XML Key Management Specification. Another effort by W3C. Used with both XML Encryption and XML signature to get cryptographic key information.
  • SOAP message security : An OASIS recommendation. Also known as WS-Security. Describes how to provide the confidentiality, integrity and authentication requirements of SOAP messages. Make use of XML encryption and XML signature standards along with other types of security tokens. The specification is designed to be extensible, so that it can support multiple security token formats.
  • SAML : Security Assertion Markup Language is a definition from OASIS. Provides a mechanism to exchange authorization and authentication information in a vendor-neutral way.


Securing your Web Service

When you plan to secure your Web services, you need to first understand exact security requirements. If you do not care about providing message-level security, you could easily use only the transport-layer security. For example, Web services over HTTPS.

On the other hand, If you do care to protect messages even after transportation, or, you have multiple intermediaries that are involved in a message delivery process, then you need to go for messagel-level security. Alternatively, you may use both these approaches in combination. For example, you might want to use transport-layer security to provide confidentiality, and message-level security for authentication purposes.

Apart from understanding the above mentioned standards such as XML Encryption, XML Signature, Keys management in SOAP message security, you need to also understand how to configure various security features. Common standard for this in Web services is to follow WS-Policy and WS-Security Policy specifications. These two specifications define a behavioral model for Web services. For example whether a message need to be encrypted, signed, what type of tokens to be included in the security header etc. Also keeping in mind, that a requirement for one Web service may not be valid for another. Thus defining service-specific requirements might be necessary.


Web Services Security Efforts

Apache Rampart implemented both in Java and C, provides security for Web services. Apache Rampart/Java is designed to work with Apache Axis2/Java Web services engine, whilst its C counterpart works with Apache Axis2/C Web services engine. Not only in Java and C, you can also secure your Web services implemented in PHP and Ruby, thanks to WSO2's efforts to provide a Web services frameworks in these languages. i.e. WSO2 WSF/PHP and WSO2 WSF/Ruby. All these frameworks are offered free and pen source under Apache license 2.0. WSF/C, WSF/PHP and WSF/Ruby are secured with Apache Rampart/C. WSO2 WSAS (Web Service Application Server) and WSO2 ESB are secured with Rampart/Java.

All these application servers and Frameworks provides a comprehensive solution to host and consume web services, with each component ensuring security just by setting up few configuration settings.



As information systems become decentralized to cater for greater business productivity and agility, Web services have become the preferred technique for executing such technology. To enable Web services at an enterprise level, it is necessary to protect them from a variety of threats common to information systems in general and those that are unique to the Web services model. There are a number of standards developed to secure Web services. It is important that we follow these standards to ensure the development of software components that are inter-operable and yet, secure.



  1. Apache Axis2/Java
  2. Apache Axis2/C
  3. Apache Rampart/Java
  4. Apache Rampart/C
  6. WSO2 WSF/C
  7. WSO2 WSF/Ruby
  8. WSO2 WSAS
  9. WSO2 ESB
  10. WS-Security Policy specification
  11. WS-Security Specification
  12. WS-Trust specification
  13. WS-Secure Conversation specification
  14. XML-Signature Syntax and Processing
  15. XML Encryption Syntax and Processing



Malinda Kaushalye Kapuruge is a Senior Software Engineer, WSO2 Inc. kaushalye at wso2 dot com

About Author

  • Malinda Kaushalye
  • Tech-lead
  • WSO2 Inc.