Web Services Are Loosely Coupled Computing Services That Can Reduce the Complexity of Building

Securing Web Services and Java WSDP

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.

Overview of Information Security

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:

·  Authentication: Ensures that the sender and receiver are who they claim to be. Mechanisms such as username/password, smart cards, and Public Key Infrastructure (PKI) can be used to assure authentication.

·  Authorization or Access Control: Ensures that an authenticated entity can access only those services they are allowed to access. Access control lists are used to implement this.

·  Availability: Requires that uninterrupted services are provided to authenticated and authorized users.

·  Confidentiality: This assures that information in storage and in-transit are accessible only for reading by authorized parties. Encryption is used to assure message confidentiality.

·  Integrity: Ensures that information, either in storage or in-transit cannot be modified intentionally or unintentionally. Digital signatures are used to assure message integrity.

·  Nonrepudiation: Requires that neither the sender nor the receiver of a message be able to legitimately claim they didn't send/receive the message.

Secure Sockets Layer (SSL)

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:

·  Authentication: The server presents the browser with a set of credentials in the form of a server certificate, which is used to verify that the site is what it claims to be.

·  Confidentiality: SSL responses are encrypted so that the data cannot be deciphered by third parties as it passes between the client and server on a network.

·  Integrity: Guarantee that data is not being modified as it is being passed between the client and server on a network.

SSL is Not Adequate for Securing Web Services

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:

1. Between the user and web site, and
2. Between the user and web service

Figure 1: Indirect access to a web service

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:

·  SSL provides point-to-point security or operates between end-points (and not applications), but for web services we need end-to-end security in which multiple intermediate nodes could exist between the two end-points. In a web services environment, there could be multiple XML-based business documents going through multiple intermediary nodes and it will be difficult for such nodes to participate in security operations in an integrated fashion.

·  SSL operates at the transport level and not at the message level. In other words, messages are protected only while in transit. That is, you cannot save the message for later to prove that it hasn't been modified.

·  SSL doesn't support nonrepudiation. Using SSL, a communicating partner cannot prove that the other party has performed a particular transaction. That is, SSl doesn't support an end-to-end audit trail from service request to service response.

·  SSL doesn't support element-wise signing and encryption. Given a large XML order document, you may want to only sign or encrypt the credit card info...and that is difficult in SSL. This is because SSL is a transport-level security scheme as opposed to a message-level scheme.

Firewalls and Web Services Security

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:

·  If the incoming SOAP message is destined to a live web service

·  If the SOAP message and its request are valid

·  If the SOAP message contains valid data

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.

Figure 2: Web services behind a 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.

Security Standards for Securing Web Services:

·  XML Signature: A standard specification developed jointly by the W3C and IETF (Internet Engineering Task Force). An XML signature is equivalent to a digital signature; it can be used to digitally sign portions of an XML document. It is used with SOAP messages.

·  XML Encryption: A standard specification developed by the W3C proposes to encrypt portions of XML documents. This specification can be used to assure confidentiality in case of a security context ranging over several SOAP intermediaries. To do that, portions of the SOAP message are kept confidential from SOAP intermediaries while the message is in transit.

·  XML Key Management Specification (XKMS): Developed by the W3C to allow clients to obtain cryptographic key information (such as keys and certificates). It also describes protocols for key management such as registration and revocation, suitable to be used together with XML Signature and XML Encryption.

·  Security Assertions Markup Language (SAML): Defined by OASIS, it outlines a framework for exchanging authentication and authorization information. It is a vendor-neutral framework to communication authentication, authorization, and attribute information of a subject.

·  XML Access Control Markup Language (XACML): The primary goal of this specification is to standardize access control language in XML syntax. Such a language can be used to express access control policies like who can do what and when. The Web Services Policy Language (WSPL), which is based on XACML, is a generic language for expressing policy information.

·  WS-Security: The OASIS Web Services Security specification defines a SOAP extension that provides quality of protection through message integrity, message confidentiality, and message authentication. It defines an end-to-end security framework that provides support for intermediary security processing. Message integrity is provided by using the XML Signature, and message confidentiality is provided by using XML Encryption. You can digitally sign and encrypt any combination of message parts.

·  Liberty Alliance: This consortium of commercial and noncommercial organizations has the vision of enabling a networked world where individuals and businesses can conduct transactions while protecting the security and privacy of identity information. Specifications created by this consortium support and include other standards such as SAML, XML, and WS-Security.

Will These Standards Work Together?

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:

1. Have the authentication information for each web service included in the initial SOAP message
2. Use a user's authentication list in a central database.

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.

Java WSDP 1.5

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.

Java WSDP 1.5, XML, and Web Services Security

Security can be provided at two levels:

1. Transport-level security: This can be done using JAX-RPC for either basic authentication or client-certification authentication over HTTP/SSL.
2. Message-level security: The security information is contained within the SOAP message. In other words, the security information travels along with the message. This has the benefit of allowing message parts to be transported without intermediate nodes seeing or modifying the message. For example, a portion of a message can be signed by a sender and encrypted for a particular receiver. The encrypted portion can only be decrypted by the intended receiver.

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.

Java WSDP 1.5 XWS-Security Framework

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:

·  Support for securing JAX-RPC applications at the service, port, and operation levels.

·  Command-line tools that provide specialized utilities (such as pkcs12import and keyexport) for keystore management. The pkcs12import tool allows public-key cryptographic standards version 12 (PKCS-12) files to be imported into a Java KeyStore. The keyexport tool is used to export a private key from a Java KeyStore into a file.