Section 12.4. End-to-End Security When Intermediaries Are Present

12.4. End-to-End Security When Intermediaries Are Present

As discussed in Chapter 4, "SOAP," SOAP is architected to allow messages to go through one or more SOAP intermediary nodes before they reach their final destination. In this example, some information in the travel request flows through Fabrikam456 to the travel suppliers. Fabrikam456 augments the travel request and modifies some sections.

Intermediaries must be able to access the header and the body, possibly deleting and/or adding some header blocks, so network- or transport-layer security such as IPSec and SSL/TLS needs to be terminated at each intermediary. The intermediary might not be able to reestablish the security information from the original sender because it might not be authorized (that is, it doesn't have original sender's keys). This situation is depicted in Figure 12-3. This structure is appropriate if the intermediary is trusted.

Figure 12-3. Point-to-point configuration.

However, if one does not want the intermediary to access or modify some parts of the message, or if the end services want to authenticate the requester without trusting the intermediary, then it is necessary to set up an end-to-end security context, as shown in Figure 12-4. Also, some of the information might require additional levels of protection such as:

• End-to-end integrity, for example, for the original travel request and the original sender,

• End-to-end confidentiality, for example for frequent flier numbers, account numbers, and similar information.

Figure 12-4. End-to-end configuration.

Establishing such end-to-end security requires a mechanism above the transport layer. This is why a message-layer security is required: this is precisely what WS-Security provides. The original message must be secure end to end, independent of the point-to-point protocols.

WS-Security: SOAP Message Security provides support for end-to-end message security. This specification introduces three key concepts:

• Security tokens SOAP messages can contain security tokens with authentication information. These tokens can flow with the message through intermediaries to vouch for message claims to downstream systems.

• Signature elements SOAP messages can contain digital signature information for all or part of a message. In this example, CompanyABC's application signs the message or part of the message. The downstream travel services use the signature to verify that CompanyABC's original request has not been changed, and to vouch that the message came from CompanyABC.

• Encryption element SOAP messages can be encrypted, either wholly or in part. In this example, CompanyABC's application encrypts some information in the original message so that only AirlineXYZ can read it.

WS-Security defines a SOAP Security Header format that contains subelements for security tokens, signature elements, and encryption elements. These concepts are presented in more detail later in this chapter.