Mastering Web Services Security
Bret Hartman, Donald J Flinn, Konstantin Beznosov, Shirley Kawamoto
Book Summary by Brad Ruppert - February 25, 2009
Web Services provide a new avenue for businesses to extend their products and services to
customers and other businesses far beyond what was once possible. This extension enables a business
to increase customer loyalty, support increased sales efforts, and increase management of internal
information. Along with this additional functionality comes a myriad of security vulnerabilities whereby
your business’s information is not only available to your customers and employees but potentially the
confidentiality and integrity of the information is vulnerable to compromise if the web services are not
properly secured. Understanding the available technologies, systems, protocols, and architectures will
help ensure the proper security measures are taken to protect information assets, and to enable the
business to grow.
There are many benefits for using web services which include increased efficiency and
facilitation of real-time processing spanning not only the Internet but a company’s extranets and
intranets as well. Online financial institutions for example can provide their customers 24x7 accounting
functionality, bill paying, funds transferring, and currency trading. Web applications hosted on company
extranets can provide real-time data processing, and rule-based decision engines to retrieve,
manipulate, and store information across multiple enterprise systems. Universities can leverage
intranet knowledge repositories from campuses worldwide to share research findings and get answers
to questions from subject matter experts.
The goal of Information Security is to continue to enable the business to function while
protecting company assets. In the case of an online financial institution it is of utmost importance to
ensure the integrity of the data within the core systems prevent unauthorized transactions or
modifications. Within shared extranets, it is important that the availability of the systems remain
functional 24x7 so that businesses can continue to operate in their expected fashion. If one system
were to fail, it could compromise the functionality of multiple businesses that rely on the shared
services of that extranet web service. Protecting the confidentiality of information assets within a
corporate or university intranet is important to preventing data theft which could result in monetary or
regulatory damages.
Web Services are comprised of several security requirements including authentication,
authorization, cryptography, accountability, and security administration. Authentication refers to
validating a user or system’s (known as a principal) credentials against a known set of credentials to
ensure the principal is who the principal claims to be. Authorization is the rule set that determines a
principal’s access to a system or resources. This is typically determined by the principal’s role or
authority level within the application. Cryptography provides the algorithms and protocols that protect
data against unauthorized disclosure or modification. In the case of web services, cryptography
provides both encryption of data to ensure confidentiality and digital signatures to protect the integrity
of the data. Accountability provides a traceable record of security-related events to link modifications
to data back to an actual person. Security Administration refers to the security policy lifecycle which
incorporates all security requirements relevant to the security framework.
When discussing web services security, it can usually be broken down into three components
which include the stand-alone web perimeter security, e-business mid-tier security, and the pre-web
back-office security. The web tier or customer/external facing component is usually comprised of a web
server which hosts the web front end and is usually sheltered by a firewall. The mid-tier (application
tier), sits behind another firewall within the company’s internal domain, typically relays the
communication between the web front end and the back-office and controls the user’s session
information. The back-office or database backend houses the core data elements and is usually
regarded as the crown jewels of a company. Combining these three elements into a common secure
framework can be an arduous challenge and is defined through a means known as Enterprise
Application Security Integration (EASI).
EASI is a technique built upon Enterprise Application Integration (EAI) which was a means of
unifying various applications by using a common middleware infrastructure. EASI allows new security
technologies to be implemented within each of the web services tiers without affecting existing business
components. Enabling Web Services security at each tier provides defense in depth thereby spreading
out security defenses in the event that one component is breached. One important component to
enterprise security is ensuring that data is protected from end-to-end which means that protection
mechanisms secure not only the request of data but also the reply back to the client. The key issue
when tying these security components together is developing a common security context which
contains a user’s identity and security attributes. This context must be securely maintained and
transferred between systems and applications to preserve integrity and confidentiality amongst all
environments. This challenge is actually being addressed by the Organization for the Advancement of
Structured Information Standards (OASIS) with the development of WS-Security and SAML.
WS-Security (Web Services Security) is a communications protocol that defines a standard way
to attach signature and encryption headers to SOAP messages which was originally developed by IBM,
Microsoft, Verisign, and Forum Systems. SAML (Security Assertion Markup Language) is an Extensible
Markup Language (XML) standard for exchanging authentication, authorization, and attribute assertions
and is currently geared toward trying to solve the web browser Single Sign-On (SSO) issue. Both of these
approaches enable a means of expressing a security context that is not tied to any specific vendor’s
application or environment. Their interoperability makes them important building blocks for any Web
Services security framework.
The EASI framework supports both security-aware and security-unaware applications. Securityaware applications rely on programmers to use Application Programming Interfaces (APIs) to make calls
to security policies to enforce security checks or validation. Security-unaware applications, like J2EE or
COM+ container, make calls to the security APIs on behalf of the application itself and therefore do not
rely on the programmer to build in the security function. This reduces the likelihood of security flaws
being overlooked by the programmer and increases the inherent security of the application.
Interceptors are used to make calls to these security APIs which are broken into three categories
including standard, custom and vendor security APIs. Standard security APIs are the preferred means of
implementation because they provide the most portability and stability. Examples of standard security
APIs include J2EE and COM+. Custom security APIs are typically developed when security requirements
are beyond what is offered by the standard set of APIs. In the event a company has a highly customized
rule base engine or application, it may be necessary to develop custom security APIs. Vendor security
APIs are typically not recommended because they limit their portability or interoperability with other
security products. With continually changing technologies and security standards it is recommended for
larger scale applications to focus on compatibility.
The rapid growth of the Internet has inspired an increased demand for shared services and
information sharing that protocols like Hypertext Transfer Protocol (HTTP), Simple Mail Transfer
Protocol (SMTP), and File Transfer Protocol (FTP) are capable of providing. The challenge for businesses
is to conform to a standard of interoperability that facilitates the availability of its services to its
customers and business partners. The use of Extensible Markup Language (XML) and Simple Object
Access Protocol (SOAP) has helped facilitate this business communication across independent
environments, architectures, and platforms. Along with the desire to share information comes the
challenge of shared processing. Systems need to determine not only what information to share but
which systems will be processing the information and where the bottlenecks lie. Distributed processing
is the term used to define cooperatively sharing information and processing. Common architectures like
J2EE or COM+ will simplify this task but the challenge lies in doing business with companies that do not
deploy one of these architectures.
Electronic Data Interchange (EDI) is one attempt to facilitate multi-domain processing. EDI is a
set of standards for structuring information that is to be electronically exchanged between businesses,
organizations, or government entities. There are two versions being deployed today including
Accredited Standards Committee (ASC) X12 and the International Standards Organization’s Electronic
Data Interchange for Administration, Commerce, and Transport (EDIFACT). EDI enables the exchange of
data between two completely different domains regardless of their platform, operating system, or even
the application sending the transmission. As long as the message is formatted correctly, the receiving
system only needs to parse it correctly to complete the exchange. With all its benefits, EDI should be
used more often than it actually is. Some of its major drawbacks include having a rigid structure for the
messages and that it requires specialized expensive software. Because the data is presented in a
prescribed order with fixed representation, it makes changes difficult to implement. The trouble is, if
the format doesn’t suit a business’s needs they end up having to develop various vendor/customer
specific implementations. This makes it even more difficult and expensive to maintain.
Other components that are helping to bridge the gap of interoperability throughout Web
Services are UDDI and WSDL. Universal Description, Discovery, and Integration (UDDI) can be thought of
as an Internet phone book of sorts that lists where specific Web Services are provided and by whom. It
enables businesses to publish service listings and to define how the services interact over the Internet.
In fact it is even broken out into three components like a phone book having a White Pages for address
and contact information, Yellow Pages for industrial categorizations based on taxonomies, and a Green
Pages for technical information about services exposed by a business. Web Services Description
Language (WSDL) is an XML-based language that defines the interfaces to these Web Services and
outlines the data that is to be sent and received. It is often used with SOAP and XML Schema to provide
web services like determining what functions are available on a server or special datatypes that may be
required to communicate.
Web Services continue to be a favored avenue of business growth due to the many advantages
they provide to vendors, customers, and the businesses themselves. For starters, most businesses
already have the infrastructure needed to support Web Services and communication therefore no
additional costs are required. Because Web Services can interoperate independently of the underlying
programming language, separate businesses do not need to conform to the same application or
architecture in order to communicate with each other. Most Web Services can be built on top of
existing applications so businesses don’t have to completely abandon or reengineer existing systems.
Because Web Services are loosely coupled, businesses can pick and choose which components suit their
needs from XML, SOAP, UDDI, and WSDL.
Web Services are centered around XML and therefore one drawback is the size that data is
expanded to within this format. Even SOAP messages which use XML require more storage space,
transmission time, and ultimately require more processing power to parse. Despite these hindrances,
the advantages far outweigh the negatives so XML continues to be used because of its flexibility to work
with a multitude of different environments.
Several security issues that exist with Web Services include exposing internal systems to the
outside attackers, establishing trustworthy security associations between applications, and intermingling
different security technologies between separate businesses. Firewalls can be configured to deny all
traffic other than HTTP requests but this alone does not prevent a malicious user from getting access to
your internal systems. Security provided by Public Key Infrastructure (PKI) works well for client/server
communications but is not suited to protect multiple applications tied together. When it comes to
interfacing multiple security technologies between businesses sometimes an agreement must be made
to decide on a similar technology. If an agreement cannot be made a bridge would need to be built to
link the technologies together. The latter can be an expensive and time consuming solution.
Ensuring that the proper security precautions are in place can only come from performing tests
against your systems. Along with performing security assessments and information security audits, it is
recommended that an external company be contracted to perform penetration tests to identify
vulnerabilities and help to recommend solutions. The costs involved with performing these vulnerability
assessments will far outweigh the costs involved with having to explain to your customers why their
data was stolen.