Chapter 3: Implementing Transport and Message Layer Security

 

Retired Content
This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Chapter 3: Implementing Transport and Message Layer Security

Web Service Security: Scenarios, Patterns, and Implementation Guidance for Web Services Enhancements (WSE) 3.0

Microsoft Corporation

patterns & practices Developer Center
Web Service Security: Home
December 2005

Download	Download this guide in PDF format
Community	Web Service Security Community Workspace [Content link no longer available, original URL:https://go.microsoft.com/fwlink/?LinkId=57044]

Contents

Introduction
Important Concepts
Transport Layer vs. Message Layer Security

Introduction

This chapter builds on the first two chapters in this guide to demonstrate how you can implement the patterns described in those chapters using Microsoft technologies. The chapter is divided into two sections. The first section provides three comprehensive composite patterns that focus predominantly on message layer security. These composite patterns are implementations of a number of different design patterns. The second section, "References for Transport Layer Security" discusses how you can solve many of the same security challenges using transport layer security.

Figure 1 is a pattern map that illustrates the composite patterns and references related to direct authentication.

Figure 1. Direct authentication patterns and references

Figure 2 is a pattern map that illustrates the design patterns, composite patterns, and references related to brokered authentication.

Figure 2. Brokered authentication patterns and references

Note   An implementation pattern for Security Token Service (STS) is due for release early in 2006.

Important Concepts

To fully understand transport layer security versus message layer security, it is important to understand the following concepts:

• Credentials. Credentials are a set of claims used to prove the identity of a client. They contain an identifier for the client and a proof of the client's identity, such as a password. They may also include information, such as a signature, to indicate that the issuer certifies the claims in the credential.
• Digital signature. This is an asymmetric signature that is created with the private key of a client. Digital signatures can be used to support nonrepudiation requirements.
• Security token. A set of claims used to prove the identity of a client. They contain an identifier for the client and a proof of the client's identity, such as a password. They may also include information, such as a signature, to indicate that the issuer certifies the claims in the credential. Most security tokens will also contain additional information that is specific to the authentication broker that issued the token.
• Protection scope. This term describes the scope of protection for a Web service message. Protection scope refers to the extent the message will be protected, whether it is for its entire message lifetime or only while it is in transit between servers. This is also used as a category to describe transport layer security and message layer security in Table 1.

Transport Layer vs. Message Layer Security

Transport layer security represents an approach where the underlying operating system or application servers are used to handle security features. For data confidentiality, Secure Sockets Layer (SSL) is a common transport layer approach that is used to provide encryption. Figure 3 illustrates transport layer security.

Figure 3. Transport layer security

If a message needs to go through multiple points to reach its destination, each intermediate point must forward the message over a new SSL connection. In this model, the original message from the client is not cryptographically protected on each intermediary because it traverses intermediate servers and additional computationally expensive cryptographic operations are performed for every new SSL connection that is established. Figure 4 illustrates message layer security.

Figure 4. Message layer security

Message layer security represents an approach where all the information related to security is encapsulated in the message. Securing the message using message layer security instead of using transport layer security has several advantages that include:

• Increased flexibility. Parts of the message, instead of the entire message, can be signed or encrypted. This means that intermediaries can view the parts of the message that are intended for them. An example of this is a Web service that routes a SOAP message and is able to inspect unencrypted parts of the message to determine where to send the message, while other parts of the message remain encrypted. For an example of this, see the Perimeter Service Router pattern in Chapter 6, "Service Deployment Patterns."
• Support for auditing. Intermediaries can add their own headers to the message and sign them for the purpose of audit logging.
• Support for multiple protocols. You can send secured messages over many different protocols such as Simple Mail Transfer Protocol (SMTP), File Transfer Protocol (FTP), and Transmission Control Protocol (TCP) without having to rely on the protocol for security.

Table 1 shows a decision matrix that lists security considerations related to protection scope and how each one is supported by transport or message layer security.

Table 1. Protection Scope Decision Matrix

Security consideration	Message layer	Transport layer
Your application interacts directly with the Web service.	Message layer protection is usually more CPU intensive than transport layer protection.	Transport layer HTTPS provides full message protection.
Web services are hosted on a system that does not support Windows Integrated Security.	Authentication can be performed by passing credentials in the message.	Basic over HTTPS could be implemented. However, it would require manipulation of message headers.
Your company has a firewall in place between applications and Web services.	Message layer security is not affected by standard firewalls.	It is not uncommon for port 443 to be opened to support HTTPS.
You have nonrepudiation requirements.	Supports persistence of messages that include digital signatures, which can be used to support nonrepudiation requirements.	You can use authentication with X.509 client certificates to support nonrepudiation.
A Web service request can pass through message queues or routing servers.	Message data will be protected as it passes through intermediate servers.	The message data is not protected as it passes through the server, which leaves it vulnerable to attack. With message queues in particular, it is possible that a decrypted message will be persisted until a dependent application retrieves the message.
Web services may require support for multiple protocols, including SMTP, FTP, HTTP, and TCP.	You can apply message layer protection to messages independent of the protocol that you used for transporting the message.	Different protocols have different built-in mechanisms to support security, making it difficult to standardize how services are secured.
The Web service you are designing will handle a high concurrent load.	You can use security tokens to establish a session. However, message protection is usually more CPU intensive.	You can use hardware appliances to improve performance with transport layer message protection protocols, such as SSL.

Table 1 lists some of the major security considerations you should examine when deciding between message and transport layer security.

For more information on implementing message layer security, see the following composite patterns:

• Implementing Direct Authentication with UsernameToken in WSE 3.0
• Implementing Message Layer Security with Kerberos in WSE 3.0
• Implementing Message Layer Security with X.509 Certificates in WSE 3.0

There is already a lot of good information available on using transport layer security to secure Web services, so this information is provided in the form of the following references, which point you to appropriate guidance for implementing transport layer security. For more information on implementing transport layer security, see the following sections in References for Transport Layer Security:

• Implementing Brokered Authentication Using Windows Integrated Security on IIS
• Implementing Transport Layer Data Confidentiality Using HTTPS
• Implementing Transport Layer Security Using HTTPS Basic over HTTPS
• Implementing Transport Layer Security Using X.509 Certificates and HTTPS
• Implementing Transport Layer Security with Kerberos and IPSec on Windows Server 2003

Retired Content
This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.