|By Qusay H. Mahmoud, March 2005|
Web services are loosely coupled computing services that can reduce the complexity of building business applications, save costs, and enable new business models. They are the next wave, fueling e-commerce, application integration, and business-to-business (B2B) ecommerce. This is mainly because the driving force behind web services is cooperation and mutual benefit for a win-win situation.
An important characteristic of web services is that the interaction will be instantaneous, since interaction will be more from application to application (business to business) rather than from humans to applications. So, while enterprises are interested in bringing web services into the mainstream of their service-oriented architectures (SOA), security might be the driving force that is holding many enterprises from using them. Security is important for any enterprise-level web service, and of major concern as businesses will perform some transactions over the Internet with their trading partners using web services. Securing web services is crucial for financial, legislative, trust, and privacy reasons.
You might be wondering, why can't existing security standards such as the Secure Sockets Layer (SSL), which is the most commonly used mechanism for securing ecommerce transactions, be used for securing web services? The fact of the matter is that web services require end-to-end security rather than point-to-point security as provided by SSL.
This article presents an overview of information security, followed by an overview of the basic concepts for securing web services. It covers some of the prominent industry standards developed to provide comprehensive security solutions, as well as the Java WSDP 1.5 XWS-Security framework, which implements the OASIS Web Services Security (WSS) specification.
It is important to have a general understanding of information security prior to addressing elements of web services security. There are six general security services that encompass the various functions required of a security facility. These can also be considered as requirements that define information security:
The requirements discussed earlier have been implemented using SSL, PKI, and firewalls for conventional e-commerce systems operating over HTTP. SSL is a technology that allows web browsers and web servers (point-to-point) to communicate over a secure connection. SSL addresses the following security considerations:
Web services are loosely-coupled computing services that can be discovered and accessed. Multiple web services can be combined into a composite application that the individual developers of the services never envisioned.
To see why SSL is not adequate, consider a web service that can be provided indirectly to a user as shown in Figure 1. A user accesses a web site, and that web site has a system that invokes remote web services. Many web services might be deployed that way. In this scenario we have two security contexts:
The second security context, which is referred to as persistent security, requires the security of the SOAP request/reply message (between the web site and the web service) to be assured over more than one client-server connection. In other words, there is a need for persistent message security for SOAP documents. SSL is inadequate for this type of security. While SSL encrypts the data stream, it doesn't support end-to-end confidentiality; it leaves the data exposed between the web site and the web service provider.
SSL has several limitations when it comes to web services. The limitations can be summarized as follows:
SOAP messages are bound to HTTP or SMTP (email service), and in most intranet infrastructures messages that are destined to HTTP and SMTP are not filtered, and thus allowed to pass in/out of the system. In order for firewalls to be effective in web services, a content filtering firewall should determine:
Figure 2 shows an example of a web service provider behind a demilitarized zone (DMZ). A DMZ, which is situated outside the private network or intranet, is used to host publicly accessible services. There are no outgoing connections from the DMZ and thus if it is attacked, damage is limited to the DMZ.
A SOAP message could contain malicious data that would cause the web service to execute in an unintended mode. As SOAP messages are easily passed through firewalls, a SOAP message may contain a request to a service that is not advertised, which could compromise the service provider. For this reason, a firewall for web services should be able to filter the content of SOAP messages.
Over the past few years, several standards bodies such as the World Wide Web Consortium (W3C), the Organization for the Advancement of Structured Information Standards (OASIS), and Liberty Alliance have been developing standards and specifications to provide comprehensive security schemes for web services. The prominent standards and specifications include:
To get a feeling of how these standards work together, let's look at an operating scenario. A user may request web services from a number of service providers. The user must be authenticated for every service in order to determine his level of access or the resources that the user has access to. Asking the user to authenticate him-/her- self for each request for a service is not practical; rather a single sign-on process can be used. Using this mechanism, when the initial web service provider authenticates a user, all subsequent requests by the same user even to other service providers is automatically authenticated on that system. Two techniques can be used to implement this mechanism:
The Security Assertions Markup Language (SAML) and XML Access Control Markup Language (XACML) can be used together to implement the first technique. Other single sign-ons such as Microsoft's passport use the centralized database technique.
SAML can be used to define security information expressed in the form of assertions about objects. These SAML assertions can be digitally signed using XML Signature, and to ensure privacy, they can be encrypted using XML Encryption. The public key used for encryption can be validated and registered through XKMS. XACML can be used to define an access control policy for handling SAML assertion requests.
The Java Web Services Developer Pack 1.5 (Java WSDP 1.5) is an integrated toolkit that allows Java developers to develop, test, and deploy web services quickly and easily. The Java WSDP 1.5 is an all-in-one download containing key technologies, tools, and APIs that simplify web services development using the Java 2 Platform. The Java WSDP 1.5 provides implementations of web services standards including the Web Services Description Language (WSDL), the Simple Object Access Protocol (SOAP), and the Universal Description, Discovery and Integration (UDDI). In addition, it provides implementations for web application development such as JavaServer Pages (JSP Pages) and the JSP Standard Tag Library (JSTL). The Java WSDP 1.5 is also keeping up with key standards by providing support for the Web Services Interoperability Organization (WS-I) profiles to promote interoperability among web services, as well as OASIS Web Services Security specification. It is worth noting that despite the fact that the Java WSDP emphasizes web services, the pack is an integrated toolkit that allows Java developers to develop and deploy not only web services, but also web and XML-based applications. Such applications use common XML and web services technologies, and that is why all the related implementations are bundled together.
Security can be provided at two levels:
Java WSDP 1.5 provides a framework for JAX-RPC application developers that enable them to sign/verify SOAP messages, encrypt/decrypt parts of messages, and perform username-password based authentication. This framework (XWS-Security) is based on OASIS Web Services Security (WSS) core specification (PDF), and the implementation has been tested for interoperability with other vendors' implementations through participation in OASIS interop events. The current framework uses both Apache's XML-DSig implementation, which is based on W3C XML Signature Syntax and Processing, and Apache's XML-Enc that is based on W3C XML Encryption Syntax and Processing.
The Web Services Security (XWS-Security) framework can be used for message-level security. Information is contained within the SOAP message, and the XWS-Security framework allows that security information to travel along with the message. Message-level security is referred to as end-to-end security simply because a portion of a message may be signed and encrypted for a particular receiver, but the message may pass through intermediate nodes before reaching the intended receiver. Here, the message can only be encrypted by the intended receiver.
The XWS-Security framework supported in Java WSDP 1.5 provides the following security features:
keyexport) for keystore management. The
pkcs12importtool allows public-key cryptographic standards version 12 (PKCS-12) files to be imported into a Java KeyStore. The
keyexporttool is used to export a private key from a Java KeyStore into a file.
This framework provides the following options for securing JAX-RPC applications:
Figure 3 shows the XML security stack and how JSR 105 and JSR 106 interact with other security components today.
Note that XWS-Security calls Apache XML-Security directly, but in future releases it should be able to call other pluggable security providers. In other words, the current release of XWS-Security (in Java WSDP 1.5) is based on non-standard XML Digital Signature and XML Encryption APIs, which are subject to change. While Java WDP 1.5 includes JSR-105 (XML Digital Signature APIs), XWS-Security doesn't use these APIs simply because they are undergoing definition under the Java Community Process. Instead XWS-Security uses the Apache libraries for XML Signature and XML Encryption. The goal of XWS-Security is to move toward using JSR-105 and JSR-106 APIs.
The XWS-Security framework can be used to secure JAX-RPC applications. The framework has been integrated into JAX-RPC through the use of security configuration files. The
-security option (specified the security configuration files) of the
wscompile tool is used to generate the security code. Sample security configuration files, which are XML-based, can be found at
The driving force behind web services is cooperation and mutual benefit for a win-win situation, and therefore securing web services is crucial for financial, legislative, trust, and privacy reasons. While this can be an overwhelming task, several standards for securing web services are being developed that will help developers build them securely. This article provided an overview of the security issues for web services, discussed why SSL is not adequate for securing web services, presented the most prominent standards for securing web services, and described the XWS-Security framework in Java WSDP 1.5, which is based on OASIS Web Services Security (WSS).
To get a feeling of the effort involved in using the XWS-Security framework to build secure web services, download the Java WSDP 1.5 today. It comes with a tutorial as well as sample web services that use the XWS-Security framework.
Special thanks to Sherman Dickman and Venu Gopal of Sun Microsystems, whose feedback helped me improve this article.