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

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

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.

Flooding

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.

Auditing

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.