Web Services Overview

Web Services are XML-based messages delivered via Internet standard protocols. XML
is a text-based method for representing data, and will be discussed in greater detail in
Chapter 2, “Web Services.” Web Services messages can contain documents or procedure
invocations. Specific definitions of Web Services vary widely, and range from “A web
service is an application that exists in a distributed environment, such as the Internet”
(Sun Microsystems FAQ) to “AWeb Service is an interface that describes a collection of
operations that are network accessible through standardized XML messaging.” (Kreger
2001). Often, instead of defining a Web Service, an author describes the properties of a
Web Service or defines it in terms of the protocols normally associated with it.
For the discussions in this book, we define a Web Service as an XML-based messaging
interface to computing resources that is accessible via Internet standard protocols.
We will even go a bit beyond this to say that the Web Services messaging protocol is
SOAP, which we will describe in greater detail in Chapter 2. Please note that while Web
Services may use “the Web,” Web Services are not tied to a single transport protocol.
Although the most common way to exchange a Web Service request is via the Web
transport Hypertext Transfer Protocol (HTTP), other transport protocols, such as File
Transfer Protocol (FTP) or Simple Mail Transfer Protocol (SMTP), can also support Web
Services.
Characteristics of Web Services
Web Services expand the Web from a user front end to an application service. With Web
Services, the originator of a Web connection is no longer just the consumer or supplier
of information. The originator can participate in a distributed application environment
and issue remote procedure calls to request services. The use of Internet standard protocols
and other standards by Web Services allows services to work across diverse
environments, solving cross-platform interoperability issues.
Intranet and extranet applications are likely to be the major beneficiaries of Web Services.
Consumer-oriented applications don’t need the kind of access to distributed processing
that Web Services promise. Distributed processing is more commonly needed
for large-scale corporate applications. Additionally, for security reasons, companies
aren’t likely to allow access to the more powerful capabilities that Web Services can
provide unless there is a larger measure of trust and partnership between the parties
than exists for retail, consumer transactions.
Web Services facilitate the creation and resolution of requests involving parties from
different organizations, whether the organizations are two separate companies or two
business units within the same company. The actual requester of the service creates a
request contained in an XML message. This message may be signed for authentication
purposes by the requester, as we discuss later in this chapter.
Web Services Architecture
Web Services are an Internet protocol-based interface to processing. As one would
expect, Web Services are generally stateless and follow a request/response model of
interaction. Web Services standards provide a way to locate interfaces and exchange
data in an understandable way. For Intranet applications, SOAP messages may be
received directly by application servers. For extranet applications, because of security
concerns, SOAP messages are likely to be received by Web Servers or integration
servers that pass the messages on to the appropriate applications.
Other than the interface to the service, there are no requirements as to how the services
are provided. For instance, a Web Services front end can be added to an existing
information-processing infrastructure. This is particularly useful for organizations that
have an existing infrastructure in place. Figure 1.1 shows an example of how Web Services
can be provided in this way. Alternately, applications can be engineered to use a
consistent Web Services model in all tiers.
Services Applications
Corporations are discovering the power of Web Services-enabled e-business applications
to increase customer loyalty, support sales efforts, and manage internal information.
The common thread in these diverse efforts is the need to present end users with
a unified view of information stored in multiple systems, particularly as organizations
move from static Web sites to the transactional capabilities of electronic commerce. To
satisfy this need, legacy systems are being integrated with powerful new Web Servicesbased
applications that provide broad connectivity across a multitude of back-end systems.
These unified applications bring direct bottom-line benefits. For example:
On the Internet. A bank cements relationships with commercial customers by
offering increased efficiency with online currency trading. This service requires
real-time updates and links to back-office transactional and profitability analysis
systems.
On extranets. A bank and an airline both increase their customer bases with a
joint venture—a credit card that offers frequent flyer credits sponsored by the
bank. This service requires joint data sharing, such as purchase payment and
charge-back information, as well as decision support applications to retrieve,
manipulate, and store information across enterprise boundaries. Additionally,
employees from both companies need to access information.
On an intranet. A global manufacturer accelerates the organizational learning
curve by creating a global knowledge sharing system for manufacturing
research and development. Plant engineers on one continent can instantly share
process breakthroughs with colleagues thousands of miles away.
On the other hand, these new e-business applications can have a dark side. They can
open a direct pipeline to the enterprise’s most valuable information assets, presenting
a tempting target for fraud, malicious hackers, and industrial espionage.
Appropriate protections are a prerequisite for doing business, both for maintaining
an organization’s credibility with its stakeholders and for protecting its financial viability.
For example:
■■ The bank offering currency trading needs to protect the integrity of its core systems
from unauthorized transfers or tampering.
■■ The bank and airline in a joint venture may compete in other areas or through
other partnerships. A secure barrier, permitting authorized transactions only,
must be erected between the two enterprise computing environments.
■■ The manufacturer posting proprietary discoveries needs to ensure that competitors
or their contractors cannot eavesdrop on the system. Attacks from both
the outside and the inside must be blocked.
Enterprises rely on information security mechanisms to safeguard their Web Services
applications.
Information Security Goals: Enable Use, Bar Intrusion
Information security focuses on protecting valuable and sensitive enterprise data. To
secure information assets, organizations must provide availability to legitimate users,
while barring unauthorized access. In general, secure systems must provide the following
protections:
Confidentiality. Safeguard user privacy and prevent the theft of enterprise information
both stored and in transit.
Integrity. Ensure that electronic transactions and data resources are not tampered
with at any point, either accidentally or maliciously.
Accountability. Detect attacks in progress or trace any damage from successful
attacks (security auditing and intrusion detection). Prevent system users from
later denying completed transactions (nonrepudiation).
Availability. Ensure uninterrupted service to authorized users. Service interruptions
can be either accidental or maliciously caused by denial-of-service attacks.
To provide these four key protections, information security must be an integral part
of Web Services system design and implementation.
Web Services Solutions Create
New Security Responsibilities
The breadth of information security in Web Services applications is broader than you
might expect. Many system architects and developers are accustomed to thinking
about security as a low-level topic, dealing only with networks, firewalls, operating
systems, and cryptography. However, Web Services change the risk levels associated
with deploying software because of the increased ability to access data, and as a
consequence, security is becoming an important design issue for any e-business software
component.
The scope of Web Services security is so broad because these applications typically
cut across lines of business. There are many examples of new business models that
drive security needs:
E-commerce sites on the Internet. These rely on credit card authorization services
from an outside company. A federated relationship between an e-commerce
company and a credit card service depends on trustworthy authenticated
communication.
Cross-selling and customer relationship management. This relies on customer
information being shared across many lines of business within an enterprise.
Cross-selling allows an enterprise to offer a customer new products or services
based on existing sales. Customer relationship management allows the enterprise
to provide consistent customer support across many different services.
These e-business services are very valuable, but if they are not properly constrained
by security policies, the services may violate a customer’s desire for
privacy.
Supply chain management. This requires continuing communication among all
of the suppliers in a manufacturing chain to ensure that the supply of various
parts is adequate to meet demand. The transactions describing the supply chain
that are exchanged among the enterprises contain highly proprietary data that
must be protected from outside snooping.
Bandwidth on demand. This allows customers to make dynamic requests for
increases in the quality of a telecommunications service and get instant results.
Bandwidth on demand is an example of self-administration, in which users handle
many of their own administrative functions rather than relying on an
administrator within the enterprise to do it for them. Self-administration provides
better service for customers at a lower cost, but comes with significant
security risks. Because corporate servers, which were previously only available
to system administrators, are now accessible by end users, security mechanisms
must be in place to ensure that sensitive administrative functions are off-limits.
In each of the preceding cases, one enterprise or line of business can expose another
organization to increased security risk. For example, a partner can unintentionally
expose your business to a security attack by providing its customers access to your
business resources. As a result, security risk is no longer under the complete control of
a single organization. Risks must be assessed and managed across a collection of organizations,
which is a new and very challenging security responsibility.
Risk Management Holds the Key
A large middle ground exists between the options of avoiding e-business applications
based on Web Services altogether, fatalistically launching unprotected systems, or
burdening every application with prohibitively costly and user-unfriendly security
measures
This middle ground is the area of risk management. The risk-management approach
aims not to eliminate risk but to control it. Risk management is a rigorous balancing
process of determining how much and what kind of security to incorporate in light of
business needs and acceptable levels of risk. It unlocks the profit potential of expanded
network connectivity by enabling legitimate use while blocking unauthorized access.
The goal is to provide adequate protection to meet business needs without undue risk,
making the right trade-offs between security and cost, performance, and functionality.
Consider four different Web Services users: an Internet service provider (ISP), a hospital
administrator, a banker, and a military officer. Each has a different security concern:
■■ The ISP is primarily concerned about availability, that is, making services available
to its customers.
■■ The hospital administrator wants to ensure data integrity, meaning that patient
records are only updated by authorized staff.
■■ The banker is most concerned about accountability, meaning that the person
who authorizes a financial transaction is identified and tracked.
■■ The military officer wants confidentiality, that is, keeping military secrets out of
the hands of potential enemies.
The challenge is to implement security in a way that meets business needs costeffectively
in the short term and as enterprise needs expand. Meeting the challenge
requires a collaborative effort between corporate strategists and information technology
managers. Understanding the business drivers for information security helps clarify
where to focus security measures. Understanding the underlying application
architecture—how components work together—clarifies the most practical approach
for building system security.
Industrial experience in managing e-business information security is generally low.
Security technology is changing rapidly, and corporate management is not well equipped
to cope with risk management changes caused by technology changes. New versions of
interconnected Web Services systems and software product versions continue to appear,
and with each release, a whole new set of security vulnerabilities surfaces.
Managing security risk in distributed Web Services applications is daunting, but following
some basic rules for building security into component-based applications lays
the groundwork for a solid risk management approach. Although this book does not
provide detailed advice on security risk management, we do describe principles for
building secure Web Services applications that are independent of any specific technology
and will continue to be a guide for you as technologies evolve. Other chapters
in this book, particularly Chapter 12, “Planning and Building a Secure Web Services
Architecture,” supply many insights on Enterprise Application Security Integration
(EASI) that will place your risk-management approach on a firm foundation.
Information Security: A Proven Concern
Information security is a serious concern for most businesses. Even though the reporting
of computer-based crime is sporadic because companies fear negative publicity
and continued attacks, the trend is quite clear: Information security attacks continue to
be a real threat to businesses. According to a recent Computer Security Institute Survey,
90 percent of interviewed businesses reported that they had detected computer
security breaches in the last year. In addition, 74 percent of the businesses reported that
the attacks caused financial losses, such as losses from financial fraud or theft of valuable
intellectual property.
Threats to businesses result from both internal and external attacks. In the same survey,
71 percent of businesses said that they detected insider attacks (by trusted corporate
users). This last statistic is very important from the perspective of this book—to
meet corporate needs, a complete end-to-end security solution must address insider
attacks.
Web Services solutions blur the line between the inside world containing trusted
users and the outside world containing potentially hostile attackers. As we’ve discussed,
a primary purpose of Web Services architectures is to open up the corporate
network to the external world, thus allowing valuable corporate resources to be accessible
to outsiders. Outsiders (such as business partners, suppliers, or remote employees)
may have data access rights to corporate information very similar to those of many
insiders. As a result, protection mechanisms must be in place not only at the external
system boundaries, but also throughout the enterprise architecture.
According to a META Group survey, 70 percent of businesses view information
security as critical to their corporate mission. Because of the continuing threat, many
businesses are increasing their spending on security; large corporations are increasing
their spending the most.
We’re concerned about the way businesses spend their money on security. We’ve
seen many of them address security using a fragmented, inefficient approach, in which
various corporate divisions each build their own ad hoc security solutions. Piecemeal
security solutions can be worse than no security at all because they can result in:
■■ The mistaken belief that the system is secure
■■ Redundant spending across the organization
■■ Point solutions that don’t scale or interoperate
■■ Increased maintenance, training, and administration costs
Applying security products without thinking about how they all fit together clearly
does not work. We believe that businesses should build and leverage a common security
infrastructure that is shared across the enterprise. A unified approach to Web Services
security is the only way to address complex multitier Web Services applications,
which we’ll explain later in this chapter.
Securing Web Services
The pervasive reach and platform-agnostic nature of Web Services demands a security
framework that enables enterprises to secure and control access to applications
and data, without impeding the exchange of data that is essential for successful Web
Services
Web Services Security Requirements
Let’s begin by defining some core security services that are fundamental to end-to-end
application security across multitier applications. They are:
Authentication. Verifies that principals (human users, registered system entities,
and components) are who they claim to be. The result of authentication is a set
of credentials, which describes the attributes (for example, identity, role, group,
and clearance) that may be associated with the authenticated principal.
Authorization. Grants permission for principals to access resources, providing
the basis for access control, which enforces restrictions of access to prevent
unauthorized use. Access controls ensure that only authorized principals may
modify resources and that resource contents are disclosed only to authorized
principals.
Cryptography. Provides cryptographic algorithms and protocols for protecting
data and messages from disclosure or modification. Encryption provides confidentiality
by encoding data into an unintelligible form with a reversible algorithm,
which allows the holder of the decryption key(s) to decode the encrypted
data. A digital signature provides integrity by applying cryptography to ensure
that data is authentic and has not been modified during storage or transmission.
Accountability. Ensures that principals are accountable for their actions. Security
auditing provides a record of security-relevant events and permits the monitoring
of a principal’s actions in a system. Nonrepudiation provides irrefutable
proof of data origin or receipt.
Security administration. Defines the security policy maintenance life cycle
embodied in user profiles, authentication, authorization, and accountability
mechanisms as well as other data relevant to the security framework.
All security services must be trustworthy and provided with adequate assurance.
That is, there must be confidence that security services have been implemented correctly,
reliably, and without relying on the secrecy of proprietary mechanisms. We will
discuss the concept of building trustworthy security architectures in Chapter 12.
Moreover, all of the critical security services must be provided on an end-to-end
basis. Each Web Services transaction must be traceable from its origin through to its
fulfillment, maintaining consistent security across processing tiers and domains. This
is no simple feat when one considers the potential diversity of applications, systems,
and business processes involved in a typical Web Services transaction—and when you
consider that these distributed systems may be managed in very different ways.
Access to enterprise Web Services search and discovery mechanisms, such as UDDI,
also needs to be managed. While much of the Web Service information listed in a Web
Services directory is appropriate for all the applications or developers in the enterprise,
it is also important to provide a robust security mechanism for user authentication and
authorization. This facility is used to limit the set of users who may either access or
update Web Services directory entries, and can be managed at a central point.
Web Services security must be flexible enough to identify all participants in a transaction
based on a variety of authentication mechanisms. Web Services security must
also be able to establish a user security context at each processing tier. (A user security
context is the combination of a user’s identity and security-relevant attributes.) Sophisticated
authorization policies using the security context will be needed. The Web Services
security facility must perform auditing so that an accurate record of the steps that
occurred to fulfill a request and the identities of the responsible parties is maintained.
Finally, in order to achieve end-to-end security, the Web Services security must pass
the security context between domains or tiers, thereby establishing a consistent security
context for the entire transaction. Without this consistent security context, there is
no way to attribute actions to the right individual later. Passing the user security context
also eliminates the need for a user to reauthenticate each time his or her request
crosses from one tier to another. Thus, an additional benefit of the seamless integration
of security with Web Services is to provide single sign-on (SSO), even across organizations
using different security technologies.
Web Services require the ability to use different authentication mechanisms, establish
a security context, implement sophisticated authorization policies, and attribute actions
to the proper individuals. Consistent security must be maintained across processing
tiers and domains in the Web Services world. Flexible ways to create, pass, and establish
security contexts are needed for end-to-end security in a Web Services environment.
Providing Security for Web Services
Given the diverse nature of these distributed environments, it is not surprising that
Web Services security efforts to date have taken a “patchwork” approach. This patchwork
may include a range of existing, standalone Web security mechanisms, together
with operating system security (domain logins), communications security (SSL), applications
environment security (J2EE, COM+, .NET, or CORBA), and SSO (Netegrity
SiteMinder, IBM/Tivoli Policy Director, or others) solutions. Even electronic mail systems
can support Web Services. The problem is that each of these solutions has evolved
to solve a specific problem within a single tier or domain. While there have been
attempts to extend these solutions beyond their original scope, the results have not
been very rewarding.
Historically, ad hoc solutions have evolved informally to handle multitiered security.
This is especially true in going from one processing tier to another. For instance,
user identities can be passed from a Web Server to a business application as HTTP
header variables. This is generally done without encryption “in the clear,” based on a
trust relationship between the Web server and the business application. Once at the
application, programmatic security is used for authorization. It is up to the application
developer to decide on the authorization policy that must be enforced and to implement
it correctly. Infrastructure-provided security services are not generally used.
Informal solutions such as these tend to weaken overall system security by making it
discretionary and leaving the strength of the implementation up to the skill of the
application programmer, who typically isn’t experienced implementing security.
How have Web Services affected this security picture? First, interactions are more
complex and take place between more diverse environments. When interactions were
limited to browsers alone, they required only a transfer of data, and there were still
many security problems. Widespread use of Web Services means that direct invocation
of services can be performed over HTTP. Web Services are used to invoke distributed
procedure calls. Moreover, these requests can come from different domains, from users
and servers we know relatively little about.
Although this book concentrates mainly on the delivery of Web Services via HTTP,
they could be delivered by other protocols as well, because Web Services are based on
XML-based documents. For example, email or message systems can transport Web
Services requests and responses. These options make Web Services an even more flexible
way of delivering processing capabilities.
Finally, in traditional Web interactions, the actual user is at the other end of a virtual
connection. While HTTP itself is stateless, Web SSO systems go to great lengths to create
and maintain the notion of a session that maintains a secure connection between
the user and Web server. In such sessions, users are available to authenticate themselves
using passwords, certificates, or other mechanisms. However, with Web Services,
the originator of the request may not be available for authentication on an
interactive basis. For instance, the originator may choose to authenticate the request by
signing it. The system must be flexible enough to use identity derived in different ways
to make access control decisions.
The following diagram (Figure 1.2) illustrates new and existing security mechanisms
for securing Web Services at different security tiers. For instance, where access to
the Web Service is through a Web Server, Secure Sockets Layer (SSL) and Web SSO can
be used. At the application level, Security Assertion Markup Language (SAML) can be
used to support authentication and authorization across domains. Finally, access to a
mainframe is needed to complete the request, and a mainframe authentication system
is in place.
Existing security solutions have tended to concentrate only on one tier because they
evolved to solve a single-tier security problem. As the processing model has changed
to incorporate Web Services, so has the nature of the security problem. While new solutions
have been devised to address the Web Services model, existing security solutions
have not been replaced as system implementers have tried to leverage existing investments.
The challenge lies in weaving together this patchwork of standalone solutions
into an integrated, end-to-end security solution.