Red Hat DocumentationFuse ESBToggle FramesPrintFeedback

Introduction to SOAP Message Protection


By applying message protection at the SOAP encoding layer, instead of at the transport layer, you have access to a more flexible range of protection policies. In particular, because the SOAP layer is aware of the message structure, you can apply protection at a finer level of granularity—for example, by encrypting and signing only those headers that actually require protection. This feature enables you to support more sophisticated multi-tier architectures. For example, one plaintext header might be aimed at an intermediate tier (located within a secure intranet), while an encrypted header might be aimed at the final destination (reached through an insecure public network).

Security bindings

As described in the WS-SecurityPolicy specification, one of the following binding types can be used to protect SOAP messages:

  • sp:TransportBinding—the transport binding refers to message protection provided at the transport level (for example, through HTTPS). This binding can be used to secure any message type, not just SOAP, and it is described in detail in the preceding section, Transport Layer Message Protection.

  • sp:AsymmetricBinding—the asymmetric binding refers to message protection provided at the SOAP message encoding layer, where the protection features are implemented using asymmetric cryptography (also known as public key cryptography).

  • sp:SymmetricBinding—the symmetric binding refers to message protection provided at the SOAP message encoding layer, where the protection features are implemented using symmetric cryptography. Examples of symmetric cryptography are the tokens provided by WS-SecureConversation and Kerberos tokens.

Message protection

The following qualities of protection can be applied to part or all of a message:

  • Encryption.

  • Signing.

  • Signing+encryption (sign before encrypting).

  • Encryption+signing (encrypt before signing).

These qualities of protection can be arbitrarily combined in a single message. Thus, some parts of a message can be just encrypted, while other parts of the message are just signed, and other parts of the message can be both signed and encrypted. It is also possible to leave parts of the message unprotected.

The most flexible options for applying message protection are available at the SOAP layer (sp:AsymmetricBinding or sp:SymmetricBinding). The transport layer (sp:TransportBinding) only gives you the option of applying protection to the whole message.

Specifying parts of the message to protect

Currently, Fuse Services Framework enables you to sign or encrypt the following parts of a SOAP message:

  • Body—sign and/or encrypt the whole of the soap:BODY element in a SOAP message.

  • Header(s)—sign and/or encrypt one or more SOAP message headers. You can specify the quality of protection for each header individually.

  • Attachments—sign and/or encrypt all of the attachments in a SOAP message.

The WS-SecurityPolicy specification also defines policies for applying protection to individual XML elements, but this is currently not supported in Fuse Services Framework.

Role of configuration

Not all of the details required for message protection are specified using policies. The policies are primarily intended to provide a way of specifying the quality of protection required for a service. Supporting details, such as security tokens, passwords, and so on, must be provided using a separate, product-specific mechanism. In practice, this means that in Fuse Services Framework, some supporting configuration details must be provided in Spring XML configuration files. For details, see Providing Encryption Keys and Signing Keys.

Comments powered by Disqus