Security in a Loosley Coupled SOA Environment
Authorization and authentication
In the traditional security model, the system's security apparatus, such as a firewall or virtual private network (VPN), screens out unauthorized (human) users. However, an SOA demands that the architecture be more flexible and open to access from multiple systems to facilitate reuse and composition of new applications. If the systems are exposed as services but a new security mechanism is not enforced, a hacker could configure a machine to impersonate a vendor's system and make erroneous or fraudulent service calls. Because of the large-grained nature of the security mechanism, the manufacturer has no way of knowing that the machine requesting the user of the
Figure 4 In the unsecured SOA, the often coarse-grained security mechanisms of machine-to-machine interaction raise the risk of unauthorized use of web services.
web service is neither authorized nor authenticated. Figure 4 illustrates the structure of this risk. Obviously, unauthorized use of a mainframe computer is a serious security breach.
Authentication, the process that verifies identity, is a distinct issue but one that is related to authorization. In authorization, you establish whether a particular user has the permission to proceed with the task it is requesting. In authentication, you prove that the user is actually the user it claims to be. In the unsecured SOA, achieving reliable authentication is difficult. In the example shown in figure 4, the unauthorized machine user might also be faking its identity.
Privacy and integrity
Privacy, the ability to conduct business without unwanted eavesdropping, and integrity, the ability to have confidence that messages are not modified in transit, are major factors in IT security. As we have seen in numerous incidents, hackers and others often listen in on message traffic and modify those messages for purposes of mischief or crime. An infrastructure that cannot guarantee a high level of privacy and integrity is not adequately secure.
In an unsecured SOA, as shown in figure 5, an unauthorized machine can intercept and "listen in." This unauthorized SOAP-intercepting machine can pass the messages along to other unauthorized users for the purpose of fraud or malicious mischief. For example, if the manufacturer were making something related to national security, then it would be concerned that information about inventories, delivery dates, materials and so on would fall into the wrong hands. The unauthorized SOAP-intercepting machine can also modify the SOAP message in transit and deliver
Figure 5 Unauthorized interception, rerouting, and modification of SOAP messages in a nonsecure SOA.
a false message to the requesting machine. Therefore, the potential for fraud and misuse in this scenario is great.
This scenario highlights the need for encrypting the SOAP messages between systems. In the past, this has typically been handled by a network security apparatus like a VPN. However, due to the open and distributed nature of an SOA, it quickly becomes impossible to secure each machine-to-machine interaction in this manner. In the absence of SOAP encryption, an intercepted SOAP message can be understood, literally, by everyone. SOAP was designed to be universally understood, so a SOAP message can be received by a legitimate user or hacker without any distinction.
With an unsecured SOA open to all comers, malicious, unauthorized users can "flood" it with service requests and render it inoperable. In the same way that hackers brought down such websites as Amazon.com with bogus requests, a malicious, unauthorized user can bring about a denial of service (DoS) attack on an unsecured SOA. Figure 9.6 illustrates this risk. One factor that makes the risk of DoS very serious is the inability of the SOA to monitor or assure the service levels of its web services. (A web service's service level is a defined measurement of the web service's performance. For example, a web service might have to adhere to a service level of responding to a SOAP request in 10 milliseconds.) If hackers attack, the unsecured SOA has no inherent way of telling if it is being overloaded. The unsecured SOA cripples the ability of system administrators to identify and respond to security problems in a timely manner.
An audit log is a fundamental tool of IT security. To examine security performance and diagnose security problems, security personnel must have access to accurate logs of system behavior. The unsecured SOA has no message and transaction logging mechanism. After a service has been invoked, there is no way to determine who has used the service and from where the request originated. As a result, no audit trail exists
Figure 6 Unauthorized "flooding" of web service requests in an unsecured SOA.
that can be used later to investigate possible breaches in security; there is no way to
determine who has done what and at what time.
Page 2 of 3