Security in a Loosley Coupled SOA Environment
I ask Jay if he recalls an aftershave commercial from a few years back where a man gets a crisp slap on the face but responds by saying, "Thanks, I needed that!" I tell him that's how I feel whenever the subject of SOA security comes up. It's a slap of cold, hard reality that wakes us up to the kinds of serious challenges we have to overcome to fulfill the vision of the SOA. Indeed, from this point on the book deals with the pragmatic but crucial considerations brought on by developing and implementing an SOA in real life. Yet, we should welcome the slap on the face. We need to know what stands in our way. So now that we have spent eight chapters building up the SOA, we have to look at a very real and troubling issue that has the potential to be a "showstopper" for the entire trend: security.
Although the IT community is embracing service-oriented architecture because of its promise of efficiency and improved IT management, security problems are causing many to proceed slowly, or not at all, with SOA implementations. Security has always been a concern for IT managers at large companies. Major systems have typically been designed to protect against unauthorized use, intrusion, and viruses. Today, however, the issue has taken on even more seriousness in the wake of terrorist attacks and global viruses.
While SOA security concerns abound, virtually all IT managers are realizing that they must soon identify and implement security solutions for SOAs because their developers are exposing applications as web services using the new generation of development tools. A pressing need exists, therefore, to solve the security risks in the SOA.
RISKS OF LOOSE COUPLING
The SOA's inherent security problems stem from the ways in which the SOA replaces traditional security parameters with new, open standards. The security problem is twofold in that not only are the new standards completely open-no one owns them-but they were also developed without security in mind. Web services were developed over a period of years by industry consensus as a way to, among other things, enable the creation of reusable code, simplify development, and streamline system integration. While these goals were met, the open standards that emerged have not yet fully addressed security. Specifically, XML, SOAP, WSDL, and UDDI are open standards that enable the transmission and description of data and procedure calls between systems. However, none of these open standards contain any inherent security aspects of their own. If left alone, they are completely nonsecure. In fact, web services were designed to be able move efficiently through firewalls. This very loose coupling actually decreases their usability in this regard. In the past, a company's own employees could hardly access needed data, let alone the "bad guys." Now, with open standards, any 12-year-old with an Internet connection can access openly exposed transactions as readily as your authorized personnel.
To illustrate the security problems inherent in SOAs, let's look at the example of a supply-chain management process that involves a manufacturer and three vendors. Figure 9.1 represents the traditional B2B security environment. Each trading partner communicates with the manufacturer using a private network. Encryption may be used, but the manufacturer and vendor can both be fairly confident that their communication is private. Authentication (the user is who he says he is) is coded into the application, so the manufacturer can be relatively confident that Vendor A is actually Vendor A. Authorization (the user is allowed to use the system) is coded into the applications themselves as well as being handled by the security infrastructure of the entity originating the transmission.
Though secure, this traditional setup is costly and complex to maintain. Modifications to the manufacturer's application will automatically require custom revisions to the vendor's application or else they will not be able to communicate. Flexibility in extending the functionality of these connected applications is limited to the amount of custom interface development that each trading partner wants to finance.
If the manufacturer and its vendors decide to expose their applications as web services in an SOA, depicted in figure 2, they benefit from greatly increased flexibility
Figure 1 Traditional security arrangements in an architecture that connects a manufacturer and its suppliers might involve a separate firewall and proprietary security interface for each system.
but face security risks. Applications developed in this environment have numerous potential functional advantages over the traditional model, including "pulling" order data out of the system based on anticipated demand. Unfortunately, however, the SOA shown in figure 2 also contains a variety of security risks. Let's look at each of these risks in turn.
Machine to machine
To get a good grasp of SOA security issues, it important to understand that most security infrastructure is geared to human-to-machine interactions while web services involve scalable machine-to-machine interaction. Until recently, the majority of attention and product development has been given to the fairly well-understood human-to-machine web access space. This includes products that provide identity
Figure 2 This is an unsecured SOA version of the EA shown in figure 1. It is completely open, and as a result is vulnerable to security problems related to authorization, authentication, privacy, integrity, and auditing.
Figure 3 Contrast between human-to-machine and machine-to-machine communication. In most machine-to-machine scenarios, security is more coarse-grained than in human-to-machine interactions. The result is a less secure infrastructure.
management and single sign-on (SSO) solutions for users accessing systems via a web browser. The machine-to-machine interactions have received less attention, relying on their essential obscurity, a network security apparatus, or a binary security mechanism such as super-user access or key exchange, both of which are typically embedded in the applications themselves.
The reason for this is simple-the majority of applications were monolithic,
thereby minimizing the number and complexity of machine-to-machine interactions.
If organizations begin deploying an SOA without giving due consideration to alternative
security mechanisms, unauthorized users may find it simple to penetrate and
evade detection because the systems are now directly exposed in a standards-based
manner and the security mechanisms used are either nonexistent or very simple and
"large-grained." When we refer to a system as being large grained, we mean that its
ability to discern subtle differences in security situations is limited. Figure 3 illustrates
the contrast between the human-to-machine communication in a traditional
security environment and the increasingly common machine-to-machine communication
in the SOA that causes so many security issues.
Page 1 of 3