List of Figures

Chapter 1. SOA requires new approaches to security

Figure 1.1. In a typical enterprise, applications are built for end users and the mechanisms for applications to interact with each other are ad hoc: database, RPC, files, and so on.

Figure 1.2. Instead of ad hoc mechanisms for reuse, in SOA, applications provide services for other applications. Some applications may be only consumers. Services are brought together and managed by an ESB.

Figure 1.3. A single server application may have several independent functionalities to offer to the clients, but has only one security module. All the security decisions are taken by the application only and are centralized.

Figure 1.4. Here are three server applications, including one from a partner. The client applications can make use of services from any of these applications. Naturally, no single application controls or has a complete view of the security model.

Figure 1.5. John, a customer of the ACME brokerage firm, is placing an order. As ACME has integrated its applications with the payment services offered by John’s bank, John can pay for his order directly from his bank account. John attaches his bank account information to his order and sends both securely to ACME. ACME then places a money transfer request with John’s bank. Note the security hole in this arrangement. ACME knows the details of John’s bank account and an administrator at ACME may be able to misuse this information.

Figure 1.6. The message from John to the bank is in a different envelope inside the envelope to the ACME firm. ACME can only open its envelope, so the letter to the bank is safe from everybody else.

Figure 1.7. Security can be implemented as an infrastructure service, for example, offered by the ESB. This approach avoids the problems that arise when particular security models are hard-coded into applications. See also figure 1.4.

Chapter 2. Getting started with web services

Figure 2.1. Screenshot of tcpmon showing the SOAP request and response messages captured in example 1. tcpmon is a tool available with Apache Axis to inspect messages received and sent by a service. It acts like a proxy, relaying requests and responses to their respective destinations after displaying them in the GUI.

Figure 2.2. Visual representation of the sample XML document shown in listing 2.1. A well-formed XML document can always be represented as a tree. Text literals in the elements become leaf nodes. So do attributes. An attribute node, such as the Type node shown here, holds a name and a value. All other items permitted in an XML document become nodes as well. For example, comments become leaf nodes too.

Figure 2.3. Three different ways of consuming web services using JAX-RPC: (from right to left) via stubs pregenerated from WSDL by a tool, via Dynamic Invocation Interface (DII), and via a Dynamic Proxy of the service interface

Chapter 3. Extending SOAP for security

Figure 3.1. Authentication in web applications can happen at three different layers. At the transport layer, SSL certificates can be used for authentication. At the HTTP layer, the basic or digest schemes that can be implemented by the browser can be used for authentication. At the application layer, the choices are endless—we can use form-based authentication, with full control over client-side and server-side for the programmer.

Figure 3.2. Three logical layers at which security in SOAP can be implemented. Unlike in figure 3.1, where the transport layer referred to TCP/SSL, the transport layer here represents higher-level protocols by which SOAP messages are exchanged. The SOAP layer refers to web services engines that can produce/consume standards-compliant SOAP messages. The application layer is free to interpret the SOAP messages, where the security can be implemented as a private standard between the producer and the consumer.

Figure 3.3. Place of header and header entries in a SOAP envelope. Within the SOAP envelope, any number of headers can be introduced prior to the body element. Any organization can make up its own header, keeping the SOAP message syntactically valid. Most useful headers are ones where there is wide industry support and tool support.

Figure 3.4. A simple request/response illustrating the use of a header entry for carrying user ID. The sender sends a user ID in the SOAP header using a WS-Security standard header. The receiver’s response is based on the user ID received from the sender.

Figure 3.5. Tcpmon screenshot showing the result of adding our header entry. Observe that the request message contains a header entry with Username in it. Also observe that the orderId in the response contains the Username provided in the request.

Figure 3.6. Illustration of how handlers can produce and consume the header entries and communicate context to a service. The client-side handler adds the header entry and the server-side handler consumes the header entry. These handlers are actually part of the sender and receiver applications, respectively, and are implemented as libraries. Notice that the SOAP message passed between the applications contains the WS-Security Header element.

Figure 3.7. Sequence in which client-side and server-side handlers are invoked during request and response flows. Client-side handlers intercept requests on their way out to the service and responses on their way in. Server-side handlers intercept requests on their way into the service and responses on their way out.

Figure 3.8. A chain of JAX-RPC handlers can be invoked on the client as well as the server-side. Handlers in a chain are called in reverse order for processing responses and faults compared to the order in which they are called for processing requests.

Figure 3.9. Without intermediaries in a message path, no addressing information needs to be provided in the envelope. The introduction of intermediaries will however require that the destination endpoint information be preserved so that the final intermediary can route the message to the destination endpoint.

Figure 3.10. Headers are often utilized to enable common services such as security and billing.

Chapter 4. Claiming and verifying identity with passwords

Figure 4.1. Screenshot of tcpmon illustrating the rejection of a request when an incorrect password is used.

Figure 4.2. Overview of an implementation of username and clear-text password-based authentication scheme

Figure 4.3. Simplest way to implement authentication: the application consults a specific password store.

Figure 4.4. JAAS provides a standard API for applications to authenticate against any password store. Administrators can configure JAAS to use arbitrary password stores. Interaction with each password store happens through a store-specific JAAS LoginModule implementation.

Figure 4.5. Flow charts depicting how the result of a JAAS login module can be combined with the results of the rest of the modules configured for an application.

Figure 4.6. Sequence diagram showing the inner workings of JAAS.

Figure 4.7. Overview of the server-side implementation

Figure 4.8. Authentication with password digests

Figure 4.9. Overview of a username/password digest-based authentication scheme.

Chapter 5. Secure authentication with Kerberos

Figure 5.1. Example of service provider abuse Kerberos was designed to eliminate. Users often tend to reuse passwords across services. A malicious service provider can easily abuse the passwords registered by users to spoof user identity on a different service.

Figure 5.2. Relationship between encryption and decryption functions: the decryption function can recover a secret encrypted by the encryption function.

Figure 5.3. To protect a secret even when using a well-known encryption function, the sender can use a secret key k that is only known to the intended receiver. The intended recipient uses its knowledge of the secret key to match the modification of the encryption function in the decryption function.

Figure 5.4. A KDC can act as a “broker” that supplies a session key.

Figure 5.5. Refinement of the KDC idea.

Figure 5.6. Further refinements to combine client identity details and session key as part of a ticket.

Figure 5.7. Authentication sequence between a Kerberos-enabled client and a service. The client application authenticates to the service without revealing the user’s password to the service. The user password is not submitted to the KDC either. Logon Session Key returned by KDC AS can only be used by the client if it is in possession of the user’s long-term key, computable from the user’s password.

Figure 5.8. Use of GSS API for the limited purpose of obtaining a Kerberos service ticket on the client-side and verifying it on the server-side.

Figure 5.9. Overview of the implementation of a Kerberos-based authentication scheme

Chapter 6. Protecting confidentiality of messages using encryption

Figure 6.1. Screen shot of etherea illustrating the capture of network data without the consent or cooperation of the participants.

Figure 6.2. Public-key encryption in action: The original message encrypted using the recipient’s public key can be decrypted using the recipient’s private key.

Figure 6.3. How signatures work: The sender attaches a message digest that is encrypted using his private key. The recipient uses the sender’s public key to decrypt the encrypted message digest. If the result of this decryption matches the digest value independently computed by the recipient, the message is proven to be intact; otherwise, a man in the middle must have tampered with the message en route.

Figure 6.4. How hybrid encryption works: The key needed for symmetric-key encryption is first exchanged securely using public-key encryption. All subsequent message exchanges use symmetric-key encryption.

Figure 6.5. How the certificate is generated. Only a part of the certificate, the digest, needs to be encrypted (as a signature) by the CA. The certificate which contains the public key of the application is guaranteed by the CA. This signing is a one-time activity—the application can use a signed certificate as long as the contents of the certificate do not change.

Figure 6.6. Sample implementation of SOAP encryption and decryption. In this example, UsernameToken is encrypted by a client-side EncryptionHandler and recovered by DecryptionHandler on the service-side.

Chapter 7. Using digital signatures

Figure 7.1. A MAC is a message digest encrypted using a shared secret key. The receiver can use a MAC as shown to detect whether the message has been tampered with along the way by a man in the middle.

Figure 7.2. DTDPKI and digital signatures provide another way to verify message integrity. Unlike with MACs, PKI does not require a shared secret. The sender signs a message by using his private key to encrypt a digest of the message. The receiver can use the sender’s public key, available from the sender’s digital certificate, to decrypt the signature and verify the message digest.

Figure 7.3. Superficial differences in how XML is serialized can result in signature mismatch. In the example shown here, the merchant’s application extracts an e-check from an order and submits it as part of a settlement request to the bank. The bank finds a signature mismatch, as the merchant’s application serializes the e-check in a slightly different fashion than the buyer’s application.

Figure 7.4. XML canonicalization (c14n) process divides the universe of all possible XML documents into sets of syntactically equivalent documents. Each such set can be represented by a canonical form to which every member of that set can be reduced using the canonicalization process.

Figure 7.5. Two possible schemes for canonicalizing namespace declarations on the quote element. In the first scheme, called inclusive canonicalization, all namespace declarations in scope for the quote element are included. In the second scheme, exclusive canonicalization, only those namespace prefixes that are used on quote and its descendant nodes (such as xsi:type attribute in this example) are included.

Figure 7.6. A demonstration of how fragile inclusive canonicalization can be. A seemingly innocuous and unrelated change—addition of a wsu:id attribute to the Envelope element, an ancestor of quote—changes the canonical form of the quote element.

Figure 7.7. High-level overview of an XML signature used to protect the integrity of a SOAP message.

Figure 7.8. Overview of the example implementation of signatures to guard the integrity of a SOAP request.

Chapter 8. Implementing security as a service

Figure 8.1. Security implemented as part of each service and service consumer. Each service implements its own security, which is invoked as a part of service consumer and provider. For instance, the consumer may add username and password information and the provider may validate them and grant access.

Figure 8.2. Security implemented as a separate service to offload most of the security enforcement burden from services and service consumers. Note that services and service consumers may still handle some security tasks. For example, they may have to understand how to use the security service.

Figure 8.3. The destination endpoint invokes the security service out-of-band. The burden of security is moved to a separate service. Still, the destination endpoint (that is, the service provider) must invoke it explicitly.

Figure 8.4. The source endpoint invokes the security service out-of-band. Just as before, security is handled by the separate security service. The burden of invoking it falls to the source endpoint; i.e. the consumer. Since the result should be accepted by the destination endpoint, the security service needs to implement standards such as SAML.

Figure 8.5. Both endpoints invoke the security service out-of-band. As always, security functionality is encapsulated by the security service. Unlike before, both the source and destination endpoints invoke the service, which generates and validates the security tokens.

Figure 8.6. Security service implemented as an explicitly addressed intermediary in the message path. Unlike in previous cases, no endpoint has to invoke the security service. The message is handed off by the source endpoint to the security service, which in turn relays the message to the destination endpoint, after enforcing security.

Figure 8.7. Security service implemented as an intermediary in the message path with the help of a network device. It is similar to the earlier case depicted in figure 8.6. The difference here is that the addition of the security service to the message path is done by a network device, without any endpoint knowing about it.

Figure 8.8. Overview of the example used to illustrate the concept of a centralized security service. The message is routed from the client-side to the server-side via the security service. Notice that the username and password token is replaced by the SAML assertion as the message is processed by the security service.

Figure 8.9. Details of client-side implementation in example 6. The client side adds two pieces of information using handlers: the address and the username and password.

Figure 8.10. Details of the security service implementation. The security service has a JAASAuthenticationHandler to validate the username and password and a SAMLCreationHandler to add the SAML assertion to the message. The proxy service is used to forward the message to the server side.

Figure 8.11. Details of server-side implementation. The server-side handler needs to understand and validate the assertion, and finally extract the username and password from the message.

Figure 8.12. Security token service interface defined by WS-Trust: a request for a security token (RST) is met with an RST response (RSTR).

Chapter 9. Codifying security policies

Figure 9.1. Developers today are forced to hard-code security policies into each solution. The vision of declarative security is to allow a security expert to create an enterprise-wide policy repository that each solution in the enterprise can refer to.

Figure 9.2. A design-time tool can obtain and compare the security policies of both parties, present options that are compatible with both policies, and generate code based on user choices.

Figure 9.3. Use of security policies at runtime to achieve interoperability between any two parties.

Figure 9.4. Policy-based approach to ensuring interoperability between two parties in a web service message exchange

Figure 9.5. Illustration of a policy intersection. Party 1’s policy states that party 1 can only do encryption using AES with 192/256-bit keys. Party 2’s policy states that it can only decrypt text encrypted using AES with 128/192-bit keys. The intersection of the two policies dictates that both parties use AES with 192-bit keys if they are to interoperate.

Figure 9.6. Different ways of fetching a policy: query via WS-MetadataExchange or look up policies attached to WSDL/UDDI entities as described in WS-PolicyAttachment.

Figure 9.7. WS-MetadataExchange provides a simple protocol to fetch metadata such as XSD, WSDL, and WS-Policy. The Dialect element in the GetMetaData request is used to indicate what type of metadata is being requested. To fetch a WS-Policy document, the Dialect element can be set to a URI that identifies WS-Policy as the type of requested metadata.

Figure 9.8. To compute the effective policy for a message exchange, one needs to combine the policies attached to four different subjects: Service, Endpoint, Operation, and Message. Policies can be attached to each of these subjects at the attachment points shown in this diagram.

Figure 9.9. Classification of assertions defined by WS-SecurityPolicy based on the subjects they can be associated with: Endpoints, Operations, and Messages

Figure 9.10. WS-SecurityPolicy identifies three common security patterns and defines how security policies should be bound to endpoints in each.

Figure 9.11. Sample interaction that satisfies the SymmetricBinding assertion shown in listing 9.6.

Figure 9.12. Sample interaction that matches the AsymmetricBinding assertion shown in listing 9.7

Chapter 10. Designing SOA security for a real-world enterprise

Figure 10.1. Example of two-factor authentication. In this example, username/password (something you know) is combined with a key generated dynamically by a hardware token (something you have) to create two-factor authentication.

Figure 10.2. A service wrapping a legacy application to provide a service. In fact, there are tools typically provided as part of an ESB platform that can wrap the existing functionality and offer it as a service. This wrapping can convert message format, as well as protocol; in addition it can combine multiple functions into one service.

Figure 10.3. Security may be completely taken care of by the wrapper service if the legacy application delegates security away to the underlying infrastructure.

Figure 10.4. Where legacy applications come with a home-grown security model, the wrapper service needs to map its security mechanisms to those of the legacy application.

Figure 10.5. Where a security mechanism can be plugged into the legacy application, the wrapper service may establish a security context in an external security service for subsequent use by a custom security plug-in in the legacy application.

Figure 10.6. Example of a composite service. Different approaches are possible when securing composite services such as this. No one approach is suitable in all situations.

Figure 10.7. Deployment architecture puzzle: What goes where? Match the entities on the left with the locations on the right. Break up or duplicate entities as required.

Figure 10.8. A simplistic view of an enterprise intranet consisting of one data center and one office. How services/service consumers interact with the security service is deliberately omitted from this figure, as multiple possibilities exist.

Figure 10.9. A remotely configurable security device (either hardware or software) can be used as client proxy. This technique comes in handy in small/remote branch offices that lack IT support staff.

Figure 10.10. When using multiple data centers, enterprises need to replicate credentials and policies across all data centers.

Figure 10.11. Trust relationships between multiple autonomous units of an enterprise need to be maintained. A trust relationship may be based on acceptance of security tokens issued by each other’s security service for invocation of specific services shared between the units.

Figure 10.12. Example of a firewall rule: An inbound TCP SYN that signifies an attempt to establish a new TCP connection is discarded unless it is destined to the web server or email server.

Figure 10.13. DMZ implementation using two firewalls. The inner firewall discards any attempts by DMZ hosts to initiate a new connection into the internal network.

Figure 10.14. A web server located in the DMZ is often allowed to initiate a connection to a database server within the internal network, as it is a more secure choice than moving the database server as well into the DMZ. Connection initiation attempts by the web server in the DMZ to any internal application other than the database server will be discarded.

Figure 10.15. Example deployment architecture for securing services offered to the public.

Figure 10.16. Security solution deployment for offering services to partners and consuming partner services. Note that we have not shown the security solutions used internally by each of the partners or managed service providers.

Figure 10.17. All inputs should be treated as tainted and scrubbed before using them in a service. This is especially true of any data that forms a part of a command or program.

Figure 10.18. The top half of this picture shows how a DDoS attack can be launched by flooding a service with requests from a large number of clients. The bottom half of the picture shows a strategy for coping with DDoS attacks. By filtering traffic generated by DoS attackers early and at multiple access points, the impact of DDoS on a target service can be eliminated.

Figure 10.19. By following a well-managed vulnerability remediation workflow, you can reduce the threat posed by vulnerabilities. This picture shows the steps involved in a vulnerability remediation workflow and the personnel who need to participate in it.

Appendix A. Limitations of Apache Axis

Figure A.1. Faulty W3C DOM structure created by Axis 1.x. Observe that attributes belong to a dummy document and not to the SOAP Envelope document.

Appendix D. Securing SAML assertions

Figure D.1. Two levels of indirection are recommended when signing a SAML assertion. Signature refers to a SecuityTokenReference that in turn refers to the signed SAML assertion.

Appendix E. Application-Oriented Networking (AON)

Figure E.1. Security services implemented as an implicit intermediary with the help of an AON-capable networking device.