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.