RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Implementing WS-Security with Java and WSS4J

Many organizations have now implemented solutions based on the promise of Web services, exposing those services over the Internet to enjoy maximum exposure—which then leaves them with the dilemma of securing their services to protect data and other resources. Find out how to use Java and Apache's Web Services Security for Java (WSS4J) framework to secure your Web services.


eb services have evolved into a standard means for integrating organizations using differing technologies running on heterogeneous systems and frameworks. A Web service is a business-logic component designed to be accessed across a network using industry-standard protocols and data formats. A Web service exposes a public interface described by a standard industry document format such as a WSDL file. This description document lets external systems understand and interact with the Web service over standard transport protocols such as HTTP, with messages encapsulated using standard message protocols such as SOAP.

Web services produce loosely-coupled systems that clients typically communicate with in a stateless, asynchronous manner, requiring no concern for the underlying protocol or location of the service. Unfortunately, this loosely-coupled, open communication environment is rife with potential security threats, as the next section illustrates.

Web Services Security Threats
Traditional security technologies are not sufficient for Web services security because of the need to secure data and components on a more granular scale. Because Web services use message-based technologies for complex transactions across multiple domains, traditional security processes fall short. A Web-service message can traverse several intermediaries before it reaches its final destination. Therefore, the need for sophisticated message-level security becomes a high priority and is not addressed by existing security technologies.

The following list illustrates some of the specific Web-services security threats:

  • Message Alteration—A scheming entity can attempt to alter the contents of a message, thereby compromising the integrity of the message.
  • Confidentiality—Unauthorized entities can seek to gain access to confidential information within a message.
  • Man-in-the-middle—An attacker can seek to pose as a legitimate SOAP intermediary in order to intercept messages transmitted between two or more parties. The parties, thinking they are communicating with each other, continue their conversation, but with messages that may be altered by the attacker or even originated by the attacker.
  • Identity Spoofing—Unauthorized access using authentication attacks and eavesdropping
  • Content-borne threats—Threats against XML payload elements.
  • Denial of Service (XDoS) attacks
  • Schema Poisoning—This involves manipulating the WS schema to alter the data processed by an application.
  • XML Parameter Tampering—Injection of illegitimate scripts or content into XML parameters.
  • Coercive Parsing—Injection of illegitimate content into the actual XML payload.
  • XML Routing Detours—Redirecting data addressed by an XML path
Given these threats, clearly, a secure solution is imperative.

Introduction to WS-Security
The WS-Security standard specifies extensions to SOAP messaging that provide message-level integrity, confidentiality, and authentication. WS-Security enables collaboration between other Web services security standards and protocols. Because WS-Security does not dictate one specific security technology, the WS-Security specification allows organizations to use heterogeneous security models and encryption technologies, as well as a number of different security tokens.

The WS-Security specification is concerned with three main area of focus:

  1. Security token validation (authentication)
  2. Message integrity (signing)
  3. Message confidentiality (encryption and decryption)
Here's how WS-Security treats these three areas of focus.

Validating Authentication Claims using Security Tokens
WS-Security uses security tokens to validate authentication assertions made by principals. These assertions are referred to as claims. Claims can be validated by a message recipient or by an authorized third party, such as a certificate authority.

You can use two types of security tokens:

  1. Unsigned security tokens, such as a username/password token
  2. Signed security token, such as x.509 certificates and Kerberos tickets
Preserving Message Integrity using XML Signatures
WS-Security addresses message integrity (preventing unauthorized message content modification) through XML signatures. You can use signatures to:

  • Verify the origin of a message
  • Validate encryption keys
  • Confirm the claims in a security token
Preserving Message Confidentiality using XML Encryption
WS-Security maintains message confidentiality using XML Encryption in association with security tokens to ensure that sensitive parts of a SOAP message remain confidential.

In the rest of this article, you'll see how to create these security tokens, add XML signatures, and add XML encryption to your SOAP messages so that they meet the WS-Security specifications.

Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date