Sunday Mar 26, 2006

SAAJ 1.3

The SOAP with Attachments API for Java (SAAJ) provides a standard way to send XML documents over the Internet from the Java platform.

SAAJ 1.2 was designed to handle SOAP 1.1 messages with or without attachments. SAAJ 1.3 was developed to cover the SOAP 1.2 messages as well while still maintaining the backward compatibility.


In this writeup I have listed the major changes in the SAAJ API in 1.3 release. In the next few articles I'll be writing sample codes to demonstrate the usage of these changes in the specification.


The SAAJ 1.3 RI is now available on at Do join the project if you are interested in SAAJ and post any bugs/issues that you come across. SAAJ 1.3 EA is also bundled along with JWSDP 2.0.


SOAP version 1.2 has a number of changes in syntax and provides additional (or clarified) semantics from those described in SOAP 1.1. SAAJ 1.3 is concerned with the following areas:

  1. Support for SOAP version 1.2 message constructs in the API.

  2. Factoring out the  creation of all SAAJ Factory classes into a single SPI that allows creation of SOAP version aware Factories.

  3. Addition of a few new classes and  new methods in certain existing classes and interfaces.

  4. Support for overloaded QName based methods in certain classes and interfaces.

A brief summary of the changes in SAAJ 1.3 are as follows:

  1. Support for SOAP Version 1.2 message constructs in the API: SOAP Version 1.2 has a number of changes in syntax and intoduces several new Message Constructs. SAAJ 1.3 supports SOAP Version 1.2 Message constructs.

  2. SPI for Creation of Factory Instances: SAAJ 1.3 supports SOAP Version 1.2 Message Constructs, while at the same time being backward compatible in its support for SOAP Version 1.1. It defines an SPI (SAAJMetaFactory) for factoring out the creation of SOAP Version aware Factory classes into a single place. Changing out the SAAJMetaFactory has the effect of changing out the entire SAAJ implementation. Backward compatibility is maintained by ensuring that the default protocol is set to SOAP Version 1.1.

  3. Definition of a new class SAAJResult: A SAAJResult object acts as a holder for the results of a JAXP transformation or a JAXB marshalling, in the form of a SAAJ tree. This class will  make it easier for the end user  when dealing with transformations in situations where the result is expected to be a valid SAAJ tree.

  4. Addition of overloaded methods which accept a Qname instead of a Name: QName is the preferred representation of XML qualified names, and hence we would like to introduce overloaded methods in all APIs where a corresponding method was accepting a javax.xml.soap.Name as argument. The Name interface may be deprecated in a future release of SAAJ in favor of QName.

  5. Addition of new methods in certain Interfaces and classes: A few new methods have been introduced in AttachmentPart, SOAPBody, and SOAPElement. These new methods are intended for ease of use and to assist SAAJ users when dealing with some of the newer  SOAP features.

  6. Make SOAPPart a javax.xml.soap.Node: In SAAJ 1.2 SOAPPart was implementing org.w3c.dom.Document  only.

Sunday Mar 12, 2006


This is my first entry on this weblog. I would be basically writing on SAAJ and Webservices (webservices security in particular, and anything that interests me on webservices in general). The most recent release of SAAJ and Webservices Security are part of Java Webservices Developers pack, version 2.0 which can be downloaded from here. SAAJ is now also a project on and can be accessed  here.

To begin with I wanted to put a writeup on SSL. I gave a presentation based on this writeup to my team sometime back.

What is SSL?

SSL defines a mechanism by which two endpoints exchange data in an encrypted format, such that the data exchanged offers the following characteristics:

Security: A third part, or an eavesdropper, cannot interpret the data being conveyed.

Integrity: The data received by the recipient matches that sent by the sender.

Identity: The server receiving the data is always positively identified; optionally an identity can be asserted for the client as well.

SSL operates in a layered fashion in two components. At the topmost level is the handshake protocol, which operates atop a record protocol. Both of these ride the TCP transport.

What does SSL provide?

SSL is intended to provide an encrypted means of data exchange betweena client and a server; most typically, a web browser and a web server.

As part of the handshake sequence, the server is required to identify itself via a server certificate. The inability of the server to offer such an identity causes the session setup to fail. During the handshake, protocol preferences are exchanged, and single secret session key is used via a symmetric key algorithm to encrypt and decrypt data sent across the wire. Session keys are discarded at the session's conclusion.

Point to point security:

SSL is declared to be a point to point protocol. This means that the security SSL provides is limited to the two immediate endpoints involved in the exchange of data; for example the web browser and the web server. The presence of security beyond the destination web server can not be asserted. There exists the potential for a security problem at any point downstream of the server, since the data it receives could be in clear text, and possibly could be re-transmitted to other servers that may or maynot have a public Internet presence. The ability to assert secure communication across the span of the entire application is termed “end-to-end” security, and SSL was never designed to provide this type of security gurantee.

Why do we need SSL?

The HTTP or Hypertext Transfer Protocol is the centerpiece of our current web technology. If data flows across the Internet to accomplish anything of interest, it finds its way through HTTP. This is a simple protocol capable of transmitting lots of data in a short time but with one slight drawback. Everything across HTTP is transmitted in plaintext.

Data is open to Inspection

Cleartext data flowing between browser and web server is ripe for third-party inspection for a variety of possible uses, not limited to the compromise of user-sensitive data. Other mechanisms available to a third-party eavesdropper on cleartext HTTP transmissions include the ability to make inferences about the structure of a site, and use that information as a basis on which to construct spoofing, redirections, or malformed URI attacks.

SSL eliminates the possibility of third-party examination of cleartext data by using a single shared secret key, with a symmetric key algorithm to encrypt and decrypt data on both ends of the data transaction during a session.

Inability to establish participant identities

HTTP provides no mechanism to validate that the server for which the data is intended is actually the server to which the data is delivered. Redirection attacks cause the data or websites to be spoofed or simulated on other servers without the user's knowledge.

SSL attempts to overcome this problem by mandating the use of server side certificates to assert a specific identity for a given server. The server certificate contains information about the common name of the server, which the browser can use to compare with the server requested in the client-supplied URL. If they don't match, the user can be warned and then be allowed to determine if the submission should proceed.

No gurantee of data integrity

HTTP does not pay much attention to the size, nature, stucture or type of data being transferred. As a result there is no way to validate that the data sent by one end made it to the other.

SSL addresses this problem by incorporating Message Authetication Code (MAC) in each encrypted message. A MAC is constructed by performing a hash function on the source data. The MAC value is added to the message structure that holds the data, which is then encrypted and sent to its destination. Upon receipt and decryption by the reciepient, the message data and MAC are extracted, and the same hash function is performed on the data block. The result of the reciepient hash is compared against the MAC, and if the two values match, the reciepint may conclude that the message was undisturbed in transit.

How does SSL work ?

SSL is a basket of encryption and identification technologies bundled together in a single protocol. Public-key algorithms are used to establish a secure mechanism for validation and key exchange, while a symmetric algorithm encrypts data via a shared secret sesion key. Hashing functions provide a mechanism for message integrity. The exchange of this data is covered in two layers, known as the SSL handshake protocol and the SSL record protocol. Initial protocol parameters are established at the server connection time, during the handshake protocol.

Handshake Protocol overview

The cryptographic parameters of the session state are produced by the SSL handshake protocol, which operates on top of SSL record layer. When a SSL client and a serevr start communicating, they agee on a protocol version, select cryptographic algorithms, optionally authenticate each other, and use public key encryption techniques to generate shared secrets. These processes are performed in the handshake protocol which can be summarized as follows:

  1. From the client, a CLIENT HELLO message is sent. With this initial message, the client sends its preliminary information including the protocol version, randomly generated data(ClientHello.Random),a list of cipher suites supported in decreasing order of preference and compression methods that can be imlpemented.

  2. In response, the server sends s SERVER HELLO message. The values set by the server are the protocol parameters that are set for tuis session. The server sends:

    • Protocol version

    • Session identifier – unique for a new communication session or reused from a previous session.

    • Randomly generated data – ServerHello.Random

    • Cipher suite selected by the server.

    • Compression method.

  3. The server sends its own cerificate for the client to verify.

  4. The server optionally sends a SERVER KEY EXCHANGE message.

  5. The server optionally sends a CERTIFICATE REQUEST message for client identification.

  6. The SEREVR HELLO DONE message is sent by the server to indicate the end of server hello and associated messages. After sending this message the server will wait for client response.

    Upon receipt of the server hello done message, the client should verify that the server provided a valid certificate if required and check that the hello parameters are acceptable.

  7. The client responds with a certificate if one was requested, or issues a NO CERTIFICATE alert if none is available.

  8. The client then sends a CLIENT KEY EXCHANGE message. The particular contents of this depends on the type of public key algorithm selected, but it basically contains a 48 byte PREMASTER SECRET encrpted using the public key of the server.

  9. If the client has sent a signing certificate, it will then send a CERTIFICATE VERIFY message to the server to perform certificate validation.

  10. The client now sends s CHANGE CIPHER SPEC message, indicating that the selected or pending cipher is ready to be used for subsequent communication.

  11. The client then sends FINISHED within the now current cipher algorithm, and indicates its completion of the handshake protocol.

  12. The server, in response sends its own corresponding CHANGE CIPHER SPEC and now encrypted FINISHED message to the client, concluding the handshake sequence.

  13. Secured commonucation commences.

Master secret and key generation

When RSA is used for server authentication and key exchange, a 48 byte pre_master_secret is generated by the client, encrypted under the server's public key, and sent to the server. The server uses its private key to decrypt the pre_master_secret. Both parties then convert the premaster secret into master secret as:

master_secret = MD5(pre_master_secret + SHA('A' + premaster_secret +

ClientHello.Random + ServerHello.Random)) +

MD5(pre_master_secret + SHA('BB' + premaster_secret +

ClientHello.Random + ServerHello.Random)) +

MD5(pre_master_secret + SHA('CCC' + premaster_secret +

ClientHello.Random + ServerHello.Random))

The master secret is hashed into a sequence of secure bytes, which are assigned to the MAC secrets and keys. Cipher specs different client write MAC secret, server write MAC secret, a client write key and a server write key. When generating the keys and MAC secrets, the master key is used as an entropy source, and the random values provide encrypted salt material.

The SSL record protocol

Once the SSL handshake protocol is completed, the record protocol steps in to mediate the flow of encrypted data across the connection. The protocol takes the session key established during the handshake, and begins encrypting the outbound data or decrypting the inbound data, as appropriate.

The SSL record protocol establishes the framework under which handshake and data messages are exchanged between the participants in an SSL communication. Each SSL record consists of not more than 2\^14 bytes of data known as SSLPlaintext record.

The SSLPLaintext record incorporates a structure defining the version of the protocol in use, the content of the data in the record, the length of the data, and the data itself. This record structure is then used throughout the communication merely by providing one of following four content types:

  • CHANGE_CIPHER_SPEC – Changing the cipher used for communication

  • ALERT – Indication of an error condition

  • HANDSHAKE – Negotiation of an SSL session

  • APPLICATION_DATA – Data in an existing SSL session

The algorithms used/supported for identification and key exchange:

  • RSA

  • Diffie-Hellman key exchange


RSA is the most popular algorithm.

The symmetric key algorithms used/supported:

DES, Triple DES, RC4

Hashing algorithms:





« June 2016

No bookmarks in folder