Message data can flow over insecure networks—either within an organization’s inernal network or across public networks. A conventional approach is to protect message data at the transport layer by encrypting the connection between a service and its consumer through technologies such as SSL and TLS. These technologies provide point-to-point data protection that hides message data from eavesdroppers between two points in a network.

Transport layer security is effective for many point-to-point data exchanges because the services and consumers involved are pre-defined, and the risk of unwanted exposure to sensitive data via nontrusted intermediaries tends to be low. However, when messages are exchanged as part of a composition or via message paths with various intermediaries, they can be exposed to the following threats for which point-to-point transport layer security does not provide protection:

Figure 20-1 illustrates where data can be exposed along a message path.

Figure 20.1 Point-to-point or transport layer security measures can only protect a message while in between service transmissions (green zone). It does not protect the message while in the service’s possession (red zone).

To fully protect a message’s contents, message layer encryption technologies are applied so that the security of the data is embedded and remains with the message and is only available to authorized recipients (Figure 20-2).

Figure 20.2 Data Confidentiality protects the message while in transit between services and while in the possession of unauthorized intermediaries.

This design pattern is most commonly applied to Web services via the XML-Encryption technology referenced from within the WS-Security standard. XML-Encryption converts unencrypted message data, known as plaintext, into encrypted data called ciphertext. Plaintext data is encrypted with an algorithm and a cryptographic key. The resulting ciphertext is then converted back to plaintext by the intended message recipient who possesses a key that can decrypt the data.

There are two common types of cryptography that provide data confidentiality: symmetric and asymmetric. While both follow a similar process, each has its own unique characteristics.

With symmetric cryptography, the sender and recipient share a common key that is used to perform both encryption and decryption. Symmetric cryptography relies on a common secret key and a symmetric encryption algorithm, which transforms data between plaintext and ciphertext. With asymmetric cryptography (also known as public key cryptography), the sender encrypts data with one key, and the recipient uses a different key to decrypt the ciphertext. The encryption key and its matching decryption key are often referred to as a public/private key pair.

In cases where more than one message exchange occurs between a service and consumer, a “high-entropy” shared secret can be negotiated so that the first exchange includes a shared secret that is encrypted and based on the newly generated shared secret; additional message exchanges are performed symmetrically.

Cryptographic operations are computationally intensive, which may have an impact on system resource usage. Also the task of managing and safeguarding encryption keys can introduce significant governance overhead depending on the quantity of keys used, the type of encryption chosen, and the overall key management infrastructure.

Furthermore, the security provided by Data Confidentiality is not absolute. Factors that need to be taken into account include the following:

Because the purpose of Data Confidentiality is to secure message contents, it relates directly to Service Messaging (533) and also Messaging Metadata (538), as encryption can be applied to message headers in addition to the message body content. For example, security credentials, as used by Direct Authentication (656) and Brokered Authentication (661), are often stored in message headers and can therefore be protected via encryption.

This pattern is often combined with Data Origin Authentication (649) to realize complete message layer security so that intermediary processing layers, such as those established by Service Agent (543), cannot be used to gain unauthorized access to message data.

Figure 20.3 Data Confidentiality combines messaging and security considerations.

Case Study Example

Every company involved with the forestry industry must be registered with the FRC. They are required to pay annual dues to remain in good standing and may also be forced to pay penalties as a result of policy violations.

The processing of payments can be regularly made online via a set of exposed Web services that can issue invoices, collect the payment transfer, and then confirm payments via electronic receipts. To interface with these externally facing services, organizations have the choice of submitting SOAP messages with plaintext or WS-Security-based content. The transmission channel between the organization and the FRC is encrypted via standard SSL.

Cutit Saws does not initially see the value in taking the time to outfit their payment messages with special message layer security. They only issue payments once a year and have never been fined for any policy violations. They therefore simply send a plaintext message, as follows:

Example 20.1 A sample SOAP message with no encryption.

<Envelope xmlns="http://schemas.xmlsoap.org/soap/envelope/" ...>
  <Body>
    <frc:Payment>
      <frc:InvoiceNumber>
        738345
      </frc:InvoiceNumber>
      <frc:Amount>
        $137.14
      </frc:Amount>
      <frc:Date>
        02.06.08
      </frc:Date>
    </frc:Payment>
  </Body>
</Envelope>

Alleywood, on the other hand, has become accustomed to being fined for policy violations on a regular basis. They are therefore required to issue payments to the FRC on a monthly basis.

The service consumer built by Alleywood to interact with the FRC Payment service is fully enabled to leverage their existing Web services security infrastructure. Example 20.2 shows a sample message sent from Alleywood to which Data Confidentially has been applied:

Example 20.2 A SOAP message with message layer encryption.

<Envelope xmlns="http://schemas.xmlsoap.org/soap/envelope/" ...>
  <Body>
    <xenc:EncryptedData xmlns="..." Type="...">
      <xenc:EncryptionMethod Algorithm=
        "http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
        <xenc:CipherData>
          <xenc:CipherValue>
            08FJF0239J
          </xenc:CipherValue>
        </xenc:CipherData>
      </xenc:EncryptionMethod>
    </xenc:EncryptedData>
  </Body>
</Envelope>

As shown in Figure 20-4, the FRC Payment service exposes separate operations for plain and encrypted messages. In either case, the service ensures that the payment values within the message body are encrypted before the message is further routed throughout the extensive FRC enterprise.

Figure 20.4 The transport channels between the FRC Payment service and external service consumer programs are encrypted via SSL, regardless of whether the messages themselves provide further message layer encryption.

A message sent by a consumer to a service may need to be processed by one or more intermediaries (routers, firewalls, message queues, and so on). The data contained in the message will ultimately influence the behavior of the service after it is received.

There is a risk that an attacker could manipulate messages in transit in order to maliciously alter service behavior (Figure 20-5). Message manipulation can take the form of data modification within the message or even the substitution of credentials that change the message’s apparent origin, thereby allowing an attacker to impersonate a legitimate consumer.

Figure 20.5 An attacker can design or modify an intermediary such that it intercepts a message in order to forward harmful data to a service that views it as a legitimate consumer.

Digital signature technology is used to enable message recipients to verify that messages have not been tampered with in transit and that they originate from a trusted sender (Figure 20-6).

Figure 20.6 In this scenario, the attacker could be attempting to take a valid message and substitute someone else’s credentials thereby impersonating the other party, or perhaps the attacker is trying to modify an existing message to the behavior of the service. Either way, when a message is digitally signed, the service can verify the message origin and reject the message if its origin is deemed invalid.

Data Origin Authentication within Web services is typically applied via an XML signature technology from within WS-Security, which enables the recipient of a message to verify that:

As with Data Confidentiality (641), this pattern can also be applied with symmetric and asymmetric variations. Only instead of cryptography, the application of this pattern results in symmetric or asymmetric signatures.

A symmetric signature, commonly known as a Message Authentication Code (MAC), is created by using a shared secret to sign and verify the message. MACs are generated by taking as input a checksum based on the message content and a shared secret. Each MAC can be verified only by a message recipient that has both the shared secret and the original message content that was used to create the MAC.

The most common type of MAC used in Web services is the Hashed Message Authentication Code (HMAC), an algorithm that uses a shared secret and a hashing algorithm to create the signature that is then embedded into the message. The recipient verifies this signature by using the shared secret and the message content to recreate the HMAC and by comparing it to the actual HMAC that was sent in the message.

Asymmetric signatures, on the other hand, are processed with two different keys: One (the private key) is used for creating the signature and another (the public key) for verifying it. These keys are related and are commonly referred to as a public/private key pair. The public key is generally distributed with the message, whereas the private key is kept secret by the owner (and is never sent in a message). A signature that is created and verified with an asymmetric public/private key pair is referred to as a digital signature.

For both signing and encryption purposes, asymmetric keys are often managed through a Public Key Infrastructure (PKI). Information that describes the consumer is bound to its public key through endorsement from a trusted party to form a certificate that allows a message recipient to verify the private key in a received message signature to the public key in the sender’s certificate.

It is also worth noting that asymmetric digital signatures can be used to support requirements for non-repudiation. This is because access to the private key is usually restricted to the owner of the key, which makes it easier to verify proof-of-ownership, a value that a client presents to demonstrate knowledge of either a shared secret or a private key to support client authentication. In cases where the consumer denies having performed the action, digital signatures can provide evidence to the contrary. Although digital signatures can help prove non-repudiation, their use may not be sufficient to provide actual legal proof.

Symmetric signatures, on the other hand, cannot support non-repudiation because shared secrets are known by multiple parties. This makes it more difficult to prove that a specific party used the shared secret to sign the message.

This pattern shares similar impacts as Data Confidentiality (641) because it too utilizes keys and is subject to the same performance and governance related consequences and also the same types of security risks.

Because of its close relationship with achieving message layer security, Data Origin Authentication has almost the identical set of relationships as Data Confidentiality (641).

Figure 20.7 As with Data Confidentiality (641), this pattern is focused on applying security to the message and therefore shares the same pattern relationships.

Services are commonly required to handle sensitive or private data that cannot be made available to all potential consumer programs. Furthermore, certain service capabilities may carry out internal processing that should only be triggered by certain types of consumers. Making these capabilities openly available to any consumer will jeopardize the security of the service and any resources it may access or have access to (Figure 20-8).

Figure 20.8 When a service is openly accessible, intended consumers and attackers can gain access to potentially sensitive data and logic.

The service requires the consumer to present credentials for authentication so that additional controls, such as authorization and auditing, can be implemented. The credentials that the consumer presents to the service must include a unique identifier and a shared secret in order for the service to perform authentication. An example of a unique identifier is a username and a shared secret can be a password or a password alternative.

With Direct Authentication, the service is designed to take “direct” responsibility for authentication. As depicted in Figure 20-9, the application of this pattern usually results in a process whereby the service consumer accesses the service and provides credentials that are then authenticated by the service via an identity store that holds the credentials of valid consumers for a particular identity domain. The service verifies that the credentials represent a unique consumer and that it has established “proof-of-possession” of a shared secret. If authentication is successful, the requested data is sent to the consumer, and if not, a fault message is sent to the consumer.

Figure 20.9 By having the service authenticate consumer requests against an identity store, only safe consumers can access sensitive data and logic.

Note that proof-of-possession can be established by the consumer when it provides the actual shared secret to the service or by supplying a password equivalent. One common password equivalent is a password created using a keyed-hash message authentication (HMAC) function, which uses a checksum calculated from the message and the shared secret in order to generate a password alternative. In order for the service to verify the integrity and authenticity of the message, it retrieves the user’s password from the identity store, calculates the checksum of the message, and then uses the HMAC function to recreate the password alternative. If it matches that provided by the consumer, then both the integrity and authenticity of the message has been verified. For the service to authenticate credentials, it must have direct access to the identity store, including appropriate permissions for accessing identity information.

The data stores required by this pattern can be centralized or decentralized. The former model establishes a remote store that is shared by multiple services. This can lead to runtime latency and behavioral fluctuations, depending on usage volume. A decentralized model enables some or all services to own their own individual identity stores. Although this increases autonomy, it can add to the governance burden of keeping multiple identity stores constantly synchronized.

Consumers and services must trust each other to manage keys securely. If either mismanage the keys, the service can be repeatedly and unknowingly attacked.

A benefit to Direct Authentication is that if the shared secret is compromised, then only the relationship between one service composition and one consumer is jeopardized. Other compositions using alternative identity stores may not be affected as long as each consumer retains unique credentials. However, because Direct Authentication on its own does not provide single sign-on functionality, consumers will often need to be repeatedly authenticated across services within a service composition. Although this can be avoided by caching the consumer password, it is still not recommended.

Additionally, a malicious consumer can attempt to impersonate a safe consumer by intercepting the transmission of the shared secret. It therefore is advisable that the transport of messages containing credentials be secured.

Also at risk is the identity store itself. Comprehensive security measures must be applied to ensure that its collection of passwords is not breached. This is especially a concern when regular database products are customized to act as repositories for security credentials.

As explained in the Relationships sections for Data Confidentially (641) and Data Origin Authentication (649), messages that are exchanged with security credentials can be protected by message layer security controls. These credentials are used to support Direct Authentication.

This pattern relies on the cross-service standardization achieved by Canonical Resources (237) so that composed services that authenticate each other use a common security architecture. In this type of environment, Direct Authentication is usually chosen over Brokered Authentication (661).

Figure 20.10 Direct Authentication is commonly applied together with other security patterns.

Services can have a wide variety of consumers, many of which will be unknown when the service is first designed (Figure 20-11). Establishing trust directly between a consumer and service, as per Direct Authentication (656), often requires out-of-band communication that can hinder consumers and services from interacting dynamically.

Figure 20.11 A consumer attempts to access a service with credentials that turn out to be incorrect.

Furthermore, even when Direct Authentication (656) is successfully applied, if a given consumer requires access to numerous services as part of the same runtime service activity, it may be asked to provide separate credentials for each service (Figure 20-12). In this case, the consumer may need to cache credentials for use with additional runtime activities, which may result in the consumer having to persist a password temporarily, which introduces additional security threats.

Figure 20.12 Using Direct Authentication (656), a consumer is forced to send credentials to and get authenticated by each service it composes.

An authentication broker is added as an architectural extension capable of validating consumer credentials without the need for consumers to have direct relationships with the services they need to access. Both consumers and services trust the authentication broker, allowing it to become a centralized authentication and credential issuing mechanism within the overall inventory architecture (see Figure 20-13).

Figure 20.13 The consumer submits a request with credentials to the authentication broker (1), which the broker authenticates against a central identity store (2). The broker then responds with a token (3) that the consumer can use to access Services A, B, and C (4), none of which require their own identity store.

This centralized security platform can simplify the development of individual services and can further reduce the governance burden associated with identity management.

This pattern is generally applied by the deployment of an authentication broker product or platform. The internal architectures of these products can vary in how they carry out the broker functions. However, for the most part, they follow the process illustrated in Figure 20-13 (note the use of the small lock symbol that represents a token).

Figure 20-13 demonstrates how authentication brokers can be capable of issuing tokens to consumers that are used for future interactions. For example, if the consumer requests access to a specific service, the broker can issue a token to an authorized consumer that is specifically scoped for that service, potentially allowing the consumer to repeatedly interact with the service using the same token issued by the broker.

There are a variety of security technologies associated with authentication brokers:

Claims held in security tokens can contain sensitive data and must therefore be protected in transit via Data Confidentiality (641) or the use of a transport-layer security, such as SSL. Security tokens must be signed by the issuing authentication broker. If they are not, their integrity cannot be verified, which could result in attackers trying to issue false tokens. Furthermore, without the security token being signed, there would be no way for a service to verify that the token was issued by a trusted authentication broker.

Note also that trust relationships can be established between different authentication brokers. In other words, one broker can issue security tokens that are used across organizational boundaries and autonomous security domains, each of which can have their own broker.

The centralized trust model that Brokered Authentication uses could create a single point of failure. Some types of authentication brokers, such as the Kerberos Key Distribution Center (KDC), must be constantly online and available to issue security tokens to consumers. Should such an authentication broker become unavailable at any point, it could cripple service communication. This can be mitigated somewhat via Redundant Implementation (345) or by implementing backup authentication brokers.

Additional tradeoffs associated with the validity periods of issued tokens also need to be considered. For example, the Kerberos protocol typically issues tokens for eight hours, whereas X.509 certificates will often be issued for much longer validity periods (often around a year), in which case sophisticated revocation systems, such as those provided by Certificate Revocation Lists (CRLs) and the Online Certificate Status Protocol (OCSP), are required.

Furthermore, should an authentication broker ever be compromised, attackers may gain access to confidential identify information or even the ability to falsely issue security tokens, enabling them to gain access to and perform malicious activities against many services.

Brokered Authentication is an alternative to Direct Authentication (656) but shares most of the same pattern relationships. The broker functionality provided by this pattern is often conveniently centralized via Service Perimeter Guard (394).

Figure 20.14 Brokered Authentication shares the same relationships as Direct Authentication (656) but is also commonly applied together with Service Perimeter Guard (394).