Web Services Security - Full Report

Web Services Security
An Independent Study Report - II
SUBMITTED TO THE FACULTY OF COMPUTER SCIENCES
ON GRADUATE STUDIES OF
SHAHEED ZULFIKAR ALI BHUTTO INSTITUTE OF SCIENCE & TECHNOLOGY
IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF
MASTER OF SCIENCE (COMPUTER SCIENCE)
Muhammad Jawaid Shamshad
MS/PhD (CS) 052210
May 2007
Supervised by
Naeem Janjua

______________________________________________________________________________________
2
To my Parents,
who contributed most in my studies.

______________________________________________________________________________________
3
Acknowledgements
In this era of technology with ever-increasing scope and compressed schedules,
acknowledging the contributions of everyone involved along the way is more and more
important. All too often, we move on to new projects without remembering to thank the
people who have helped us on the current one. A contribution that might on the surface
seem small can in fact make or break a project or present a fresh way of solving a
problem. It's important not only to thank people personally but also to find every
opportunity to recognize their contributions publicly.
The author's study of "Web Services Security" need lots of effort and the author wishes to
thank his colleagues and specially his advisor Sir Naeem Janjua who gave his precious
advice in conducting this study.
Muhammad Jawaid Shamshad
MS/PhD (CS) 052210

______________________________________________________________________________________
4
TABLE OF CONTENTS
CHAPTER 1...................................................................................................................... 7
INTRODUCTION ............................................................................................................ 7
1.1 LITERATURE REVIEW............................................................................................................................ 7
1.2 RESEARCH METHOD ............................................................................................................................. 7
1.3 PROBLEM.............................................................................................................................................. 7
1.4 NEED .................................................................................................................................................... 8
1.5 SECURITY BEST PRACTICE.................................................................................................................... 8
1.6 WHAT IS COVERED IN THIS STUDY?...................................................................................................... 8
CHAPTER 2.................................................................................................................... 10
WHAT ARE WEB SERVICES?................................................................................... 10
2.1 WEB SERVICE ......................................................................................................................................10
2.2 SOAP ..................................................................................................................................................11
2.3 WSDL.................................................................................................................................................14
2.4 DISCOVERING WEB SERVICE ...............................................................................................................18
2.4.1 UDDI ...............................................................................................................................................19
2.4.2 EBXML REGISTRIES .........................................................................................................................21
CHAPTER 3.................................................................................................................... 23
SECURITY PROBLEM................................................................................................. 23
3.1 WHAT IS NEEDED?...............................................................................................................................24
3.2 GOALS OF SECURITY............................................................................................................................24
3.3 NEED FOR SECURITY............................................................................................................................25
3.3 RISK MANAGEMENT ............................................................................................................................26
3.3 SECURITY: A SERIOUS CONCERN.........................................................................................................27
3.3 SECURING WEB SERVICES ...................................................................................................................28
3.3 REQUIREMENTS FOR WEB SERVICES SECURITY...................................................................................28
CHAPTER 4.................................................................................................................... 31
ENTERPRISE APPLICATION SECURITY INTEGRATION ................................ 31
4.1 EASI REQUIREMENTS..........................................................................................................................31
4.2 EASI SOLUTION ..................................................................................................................................33
4.3 EASI FRAMEWORK..............................................................................................................................34
4.4 EASI BENEFITS ...................................................................................................................................38
CONCLUSION ............................................................................................................... 39
REFERENCES................................................................................................................ 40

______________________________________________________________________________________
5
TABLE OF FIGURES
FIGURE 2.1: STRUCTURE OF A SOAP MESSAGE………………………………….………………...13
FIGURE 2.2: THE SOAP MESSAGE STRUCTURE……………………………………………..……...13
FIGURE 2.3: THE SOAP REQUEST……………………………………………………………...……...14
FIGURE 2.4: THE SOAP RESPONSE………………………………………………………….………...14
FIGURE 2.5: WSDL ABSTRACT DESCRIPTION.……………………………………………………...16
FIGURE 2.6: WSDL’S CONCRETE BINDING INFORMATION…………………………………..…..18
FIGURE 2.7 AN EBXML ARCHITECTURE IN USE………………………………………………...….22
FIGURE 4.1: KEY E-BUSINESS CHALLENGE: END-TO-END EASI………………………………...34
FIGURE 4.2: EASI FRAMEWORK…………………...…………………………………………….…….35

______________________________________________________________________________________
6
Abstract
Web Services have great potential, but according to a survey nearly half of the obstacles
to the deployment of web services are security that was more than twice the percentage of
other challenges, such as bandwidth and access issues and interoperability problems.
Organizations justifiably fear hackers and loss of confidential customer information such
as they’ve experienced with their e-commerce web sites, web services present even
greater security challenges that organizations haven’t previously encountered. This study
presents the best practices and security model for maintaining security in web services.

______________________________________________________________________________________
7
Chapter 1
Introduction
1.1 Literature Review
Literature has been collected from research papers published, like at ACM and IEEE and
chapter excerpts from some books (Books are listed in reference section), and internet.
1.2 Research Method
This study presents the logical model for maintaining state of resources in web services.
Study has been conducted by first defining the problem domain, its need, its scope, and
then its generalized logical model in practice is discussed. The study plan can be depicted
as:
 Background Review
 Problem Domain
 Requirements Specification
 Generalized logical model in Practice
1.3 Problem
Web services are a promising solution to the distributed world with its interoperability as
a major benefit, and allowing access to different data which was not accessible before
that easily. Along with the benefits of Web Services comes a serious risk: sensitive and
private data can be exposed to people who are not supposed to see it. Web Services will
never accomplish their tremendous potential and goal unless associated risks should be
properly managed.

______________________________________________________________________________________
8
1.4 Need
Since web services are normally used for business purposes to communicate between two
businesses. This communication between two businesses is so critical that it involves the
money factor, and any hacker or intruder can ruin the business of both parties. So there
should be a mechanism of securing web services. Security is even difficult to avoid in a
number of situations. One situation is Single Sing-On (SSO), when state is managed in
web services where session is established between a consumer and a provider.
1.5 Security Best Practice
There have been several best practices proposed by the security experts to secure the
system. The details of these security practices will be discussed in following chapters,
with Enterprise Application Security Integration (EASI) and WS-Security.
1.6 What is Covered in this Study?
This study starts with the introduction of the wide world of Web Services security. It
gives a quick overview of Web Services and described how they are focused on helping
applications communicate with each other, enabling interactions between applications
residing in different companies using different processing environments, what is the
structure of the message passed between consumer and provider, how they are published,
and how people can find information about the web services.
Then we will move towards the main core of this study where we will first explain some
important points about why security is important in web services environment and what
can an organization can do about securing their web services: without a good security
solution in place, many new e-business opportunities would not be feasible. It also
discusses the concept of risk management, which balances the level of security that is
required according to the business factors of cost, performance, and functionality. Since
information security is a serious concern for many businesses, in terms of both external
and internal (insider) attacks.

______________________________________________________________________________________
9
Next, it is described that the need for controlling access to Web Services data without
delaying the exchange of data. Then Web Services security requirements are described in
terms of authentication, authorization, cryptography, accountability, and security
administration. Then the mix approach of security mechanisms is specified that can be
used to support Web Services security.
After that in final chapter Enterprise Application Security Integration (EASI) is
introduced, which is used to combine the many different security technologies needed to
secure Web Services. It defines front, middle, and back-office tiers of security and
describes how they all work together to provide end-to-end security. It defines an EASI
solution in terms of a security framework, technologies, and integration techniques that
combine those technologies together. EASI framework consists of a number of layers,
including the applications, APIs, core security services, framework security services, and
underlying security products. The EASI framework enables architects to design security
systems that are flexible and able to meet future needs as business requirements and
technologies evolve.

______________________________________________________________________________________
10
Chapter 2
What are Web Services?
2.1 Web Service
There are several definitions available for describing web services and it is difficult to
give a concrete definition, but according to the authors of “The Semantic Web” [1] the
concrete definition of web service would be:
“Web services are software applications that can be discovered, described, and accessed
based on XML and standard Web protocols over intranets, extranets, and the Internet.”
Starting with the concept, the first sentence, “Web services are software applications”
expresses the main point that Web services are software applications like other usual
software applications which performs some specific tasks depending on their
implementation. In addition these software applications are available on web.
Next, according to the definition web services “can be discovered, described, and
accessed based on XML and standard Web protocols”. This part clearly states that it is
built on XML [2] which is a worldwide accepted standard and supported by majority of
the vendors. Due to this web services are interoperable and the main focus of web service
is interoperability. Other web protocols include Hypertext Transport Protocol (HTTP [3])
which is the underlying communication protocol. So web services use XML as the syntax
of their message and use HTTP to transfer that message. This is the access method. The
message is basically a Simple Object Access Protocol (SOAP [4]) envelop which is in
XML format.
Web services can dynamically be discovered by Universal Description, Discovery, and
Integration (UDDI [5]) registries. These registries keep the record of web services and
their description i.e. syntax of web services.

______________________________________________________________________________________
11
UDDI then provides the description in Web Service Definition Language (WSDL [5])
form which is also in xml format and describes the syntax of web services.
The last part of the definition state that Web services are available “over intranets,
extranets, and the Internet”. This means that web services can be public as well as private
web services for organizations internal use. Or web services can be between two
partnering organizations in a B2B solution. So it is important to understand that web
services are not only public accessible by world, but can also be private accessible within
organization’s intranet.
There is another important concept which should be cleared. Web services are not
dependent on user interfaces. Web services are only APIs which an application can call to
get information like flight schedule web service or it can be an airline reservation web
service. Since message passing is in XML format so its representation is dependent on
application how it displays it.
2.2 SOAP
Simple Object Access Protocol (SOAP) was created by Microsoft, Developmentor, IBM,
Lotus, and UserLand.
SOAP is an XML-based protocol for messaging and remote procedure calls (RPCs). That
is the format of SOAP is XML. The reason for adoption of XML as format of SOAP is
that XML is universally accepted and adopted for data encoding for platforms
independence. SOAP uses existing transport protocols like HTTP, SMPT, and MQSeries
to transfer messages or remote procedure calls.
Web services transfers XML messages in SOAP format which is like envelop and called
SOAP envelop, which contains a SOAP header and a SOAP body. SOAP header contains
the Meta information and the body contains the actual message or remote procedure call

______________________________________________________________________________________
12
(RPC) in XML syntax. This SOAP envelop is sent over HTTP between web service
consumers and web service providers or simply web service. There are also other
protocols as defined above but in usual cases HTTP is used. W3C defines SOAP as “a
lightweight protocol for exchange of information in a decentralized, distributed
environment.” [4]. SOAP provides a standard language for tying client and server
applications together on different platforms in which client application sends a SOAP
request and web service returns a SOAP response.
SOAP is associated with web services and it does not have any relation to object oriented
programming. That means a developer can create a SOAP based web service in C, Pascal
or any similar language which does not support object oriented programming. The only
thing significant is that application written in such languages can understand XML i.e.
can parse and evaluate XML documents, and can communicate over transport protocols
like which SOAP supports like HTTP.
SOAP has been adopted as the standard for Web services, and majority of the vendors
have developed SOAP APIs for their products like Microsoft for their .Net platform and
Sun for Java, thus making integration of software systems much easier.
Now let’s look at the SOAP message syntax and how it works. A SOAP message consists
of an envelope containing an optional header and a required body. Figure 2.1 shows a
SOAP envelope’s structure.
<SOAP:Envelope xmlns:SOAP=“http://schemas.xmlsoap.org/soap/envelope/”>
<SOAP:Header>
<!— content of header goes here —>
</SOAP:Header>
<SOAP:Body>
<!— content of body goes here —>
</SOAP:Body>
</SOAP:Envelope>

______________________________________________________________________________________
13
Figure 2.1: Structure of a SOAP message. The envelope features child elements that
contain the message header and body elements. [5]
The header contains information concerning how the message is to be processed. This
includes routing and delivery settings, authentication or authorization assertions, and
transaction contexts. The body contains the actual message to be delivered and processed.
Anything that can be expressed in XML syntax can go in the body of a message. This is
graphically depicted in Figure 2.2 [6].
Figure 2.2: The SOAP message structure [6]
Let’s look at an example of a simple SOAP message. This example has been taken from
the SOAP 1.1 specification. The Figure 2.3 [5] shows a simple SOAP message for getting
the last trade price of the “DIS” ticker symbol. The SOAP envelope wraps everything in
the message. The encodingStyle attribute of the SOAP envelope shows how the message
is encoded, so that the Web service can read it. Next is the SOAP body of the message
that wraps the application-specific information i.e. the call to GetLastTradePrice in the
SOAP body. A Web service receives this information, processes the request in the SOAP
body, and can return a SOAP response.
<SOAP-ENV:Envelope xmlns:SOAP-ENV=”http://schemas.xmlsoap.org/soap/envelope/”
SOAP-ENV:encodingStyle=”http://schemas.xmlsoap.org/soap/encoding/”>
<SOAP-ENV:Body>

______________________________________________________________________________________
14
<m:GetLastTradePrice xmlns:m=”Some-URI”>
<symbol>DIS</symbol>
</m:GetLastTradePrice>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Figure 2.3: The SOAP request [5]
The SOAP response for our example stock price request is shown in the Figure 2.4 [5]
that follows. Just like the request, the message is syntactically the same: It consists of an
envelope that wraps the message, it describes its encoding style, and it wraps the content
of the message in the SOAP body. The message inside the body is different. Under
SOAP-ENV: Body tag, we see that the message is wrapped in the
GetLastTradePriceResponse tag, with the result price shown in Price tag.
<SOAP-ENV:Envelope xmlns:SOAP-ENV=”http://schemas.xmlsoap.org/soap/envelope/”
SOAP-ENV:encodingStyle=”http://schemas.xmlsoap.org/soap/encoding/”/>
<SOAP-ENV:Body>
<m:GetLastTradePriceResponse xmlns:m=”Some-URI”>
<Price>34.5</Price>
</m:GetLastTradePriceResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Figure 2.4: The SOAP response [5]
2.3 WSDL
Whereas SOAP is the communication language of Web services, but speaking a universal
language is not very useful unless you can maintain the basic conversations that let you
achieve your goals. Now how can we tell what messages must be exchanged to
successfully interact with a service. That role is filled by WSDL. Web Service Definition
Language (WSDL) is the way we describe the communication details and the application-
specific messages that can be sent in SOAP. WSDL, like SOAP, is also in XML format
and developed by IBM and Microsoft. The W3C defines WSDL as “an XML format for
describing network services as a set of endpoints operating on messages containing either

______________________________________________________________________________________
15
document-oriented or procedure-oriented information”. To know how to send messages
to a particular Web service, an application can look at the WSDL and dynamically
construct SOAP messages. WSDL describes the operational information—where the
service is located, what the service does, and how to invoke the service. The format of
WSDL is very difficult to understand, but it isn’t really intended to be human-readable.
Developers do not have to understand WSDL and SOAP to create Web services. When
developer creates a Web service, most toolkits generate WSDL for you. Then the client
application generates the code for handling the Web service, generally called stub by
looking at the WSDL. Finally, the client application and the Web service can
communicate with each other.
Two pieces of information are described in a WSDL service description. One is an
abstract interface that is the application-level service description, and second is the
specific protocol-dependent detail that client application needs to follow to access the
service. These two types of information are necessary because similar application-level
service functionality is often deployed at different end points with slightly different
access protocol details. Separating the description of these two aspects helps WDSL
represent common functionality between seemingly different end points.
Abstract description is defined in WSDL as messages that need to be exchanged between
client and web service communication. Abstract interface contains components like the
vocabulary, the message, and the interaction. Vocabulary describes the type system to
provide data type definitions to exchange the information. WSDL uses external type
systems for this purpose. XSD is the most widely used but any type system is supported
by WSDL. Generally XSD is used to define standard data types like string, int, float etc,
which are supported by most of the languages like C/C++, Java, C# etc. External type
system is used to define custom data types like if developer wants to define his class or
structure and want to use that in communication. Figure 2.5 [5] shows an example in
which two data types are defined in XSD (string and int), and two data types are defined
in external schema (FlightInfoType and Ticket).

______________________________________________________________________________________
16
<message name=“GetFlightInfoInput”>
<part name=“airlineName” type=“xsd:string”/>
<part name=“flightNumber” type=“xsd:int”/>
</message>
<message name=“GetFlightInfoOutput”>
<part name=“flightInfo” type=“fixsd:FlightInfoType”/>
</message>
<message name=“CheckInInput”>
<part name=“body” element=“eticketxsd:Ticket”/>
</message>
<portType name=“AirportServicePortType”>
<operation name=“GetFlightInfo”>
<input message=“tns:GetFlightInfoInput”/>
<output message=“tns:GetFlightInfoOutput”/>
</operation>
<operation name=“CheckIn”>
<input message=“tns:CheckInInput”/>
</operation>
</portType>
Figure 2.5: WSDL abstract description. This fragment shows the string and int data
types, which are defined in XSD, and two other data types defined in external schema:
FlightInfoType and Ticket, which we assume were imported earlier in the WSDL file.
[5]
External XSD definitions are imported in WSDL using an “import” element which
specifies the location of the schema. The message elements are defined in WSDL as
aggregations of parts, and each part is described by XSD types or elements from any
other external schema. Messages provide an abstract, typed data definition sent to and
from the services. The example in Figure 2.5 shows the three messages that might appear
during a Web services interaction. The message, GetFlightInfoInput, has two parts:
airlineName, which is an XSD string, and flightNumber, which is an XSD integer. The other
two messages, GetFlightInfoOutput and CheckInInput have only one part each. Interaction is
defined by the operation and portType elements. Each operation represents a message
exchange pattern that the Web service supports. An operation is simply a combination of

______________________________________________________________________________________
17
messages labeled as input, output, or fault to indicate what part a particular message plays
in the interaction. A portType is a collection of operations that are collectively supported
by an end point. In our example, AirportServicePortType describes two operations: a single
request-response operation, GetFlightInfo, which expects the GetFlightInfoInput message as
input and returns a GetFlightInfoOutput message as the response; and a one-way operation,
CheckIn, which just takes the CheckInInput message as input.
Among the application-level functionality of the service we also need three more pieces
of information:
 what communication protocol to use (such as SOAP over HTTP)
 how to accomplish individual service interactions over this protocol, and
 Where to terminate communication (the network address).
“What” and “how” parts of this information are provided by the binding element of the
WSDL, including the communication protocol and data format specification. In short, the
binding element tells how a given interaction occurs over the specified protocol. Figure
2.6 shows a fragment from our example.
<binding name=“AirportServiceSoapBinding” type=“tns:AirportServicePortType”>
<soap:binding transport=“http://schemas.xmlsoap.org/soap/http”/>
<operation name=“GetFlightInfo”>
<soap:operation style=“rpc” soapAction=“http://acme-travel/flightinfo”/>
<input>
<soap:body use=“encoded” namespace=” http://acme-
travel.com/flightinfo” encodingStyle=
“http://schemas.xmlsoap.org/soap/encoding/”/>
</input>
<output>
<soap:body use=“encoded” namespace=“http://acme-
travel.com/flightinfo” encodingStyle=
“http://schemas.xmlsoap.org/soap/encoding/”/>
</output>

______________________________________________________________________________________
18
</operation>
<operation name=“CheckIn”>
<soap:operation style=“document” soapAction=“http://acme-
travel.com/checkin”/>
<input>
<soap:body use=“literal”/>
</input>
</operation>
</binding>
<service name=“travelservice”>
<port name=“travelservicePort” binding=“tns:AirportServiceSoapBinding”>
<soap:address location=“http://acmetravel.com/travelservice”/>
</port>
</service>
Figure 2.6: WSDL’s concrete binding information. GetFlightInfo is a SOAP RPC
interaction and CheckIn is a pure messaging interaction that uses XSD to describe the
transmitted XML. [5]
The binding describes how to use SOAP to access the service-this combination of
abstract interface and protocol and data marshalling details (the binding). A port element
describes a single end point as a combination of a binding and a network address.
Consequently, a service element groups a set of related ports. In our travel service
example, a single port describes an end point that processes SOAP requests for the
travelservice service. WSDL provides a formalized description of client–service
interaction for users and developers. During development, developers use WSDL as the
input to a proxy generator which can be a dynamic invocation proxy that generates client
code according to the service requirements either at development time or at runtime.
Proxy or stub generators relieve the developer to remember or understand all the details
of service access.
2.4 Discovering Web Service
As we have discussed that web services are now being widely used in ecommerce based
applications and to do business on web. Now most of the organizations are moving

______________________________________________________________________________________
19
towards web service. We have also discussed the technical details of web service that
how web service works and which protocols are used in communication. But knowing
this is not enough since if you don’t know who is providing which web service and what
that web service do? If you know this then you can easily get or build your own
application to communicate with that web service to expand your business. For this
purpose some kind of registry is needed who maintains a list of web services and their
feature so anyone can search his desired web service in that registry and communicate
with it. There are two major technologies for this purpose. One is UDDI (Universal
Description, Discovery, and Integration) and second is ebXML registries. UDDI was
introduced in 2000 by Ariba, Microsoft, and IBM to facilitate the discovery of business
processes. OASIS introduced ebXML in 1999, but their main focus was into consistent
use of XML and standard protocols in EDI (Electronic Data Interchange) community.
But a part of this effort, ebXML registries, is used for the discovery of ebXML business
details. Both of these technologies are worth discussing and competing technologies, so
let’s discuss one by one.
2.4.1 UDDI
Universal Description, Discovery, and Integration (UDDI) is an evolving technology and
is not yet a standard, but it is being implemented and embraced by major vendors like
Microsoft and IBM [1]. To understand simply UDDI is like a phone book for Web
services. Where organizations register their information about their web services and
applications can search for that information in the registry. So UDDI allows applications
to dynamically discover web services. When organization registers their information with
UDDI they have to provide following information [5]:
 white pages of company contact information,
 yellow pages that categorize businesses by standard categorization, and
 Green pages that document the technical information about web services, like
WSDL.

______________________________________________________________________________________
20
White pages may include information about a company or organization like organization
name, their contact information like their phone numbers and email addresses,
description of their business, and links to external sources and documents where their
business is described in more detail.
The yellow pages describe the categories or classification that what type of information
their web services provide, plus their products, industry codes, and geographic index.
The green pages describes their ebusiness rules that how to do business with the web
services they have exposed, what are their business rules, and how to invoke the web
service i.e. WSDL.
It is worth noting that these registries can be public or private within organizations where
only inter organization communication is needed. For internal integration, the use of
UDDI private registries is of much value today. Within a large organization, where
several large enterprise applications may need to interoperate, can use UDDI registries
which can be helpful for discovering how to do so. The use of such a private registry
could potentially minimize the use of interoperation documentation and reduce
integration and development time for legacy enterprise applications. Once applications
have been built on web services, and once the interfaces have been described in WSDL
and published in a private UDDI registry, other programs and projects within your
organization can dynamically connect and begin to interoperate [1]. Private registries are
therefore secure since these are inter-organization and no alien is allowed to interfere and
it will be operated according to the organization’s policy. You can also use public
registries to expose your business but it is a long debate that putting your organizations
asset into a public registry is risky [1], but after all there are also alternatives and
resolution to this problem, like you can put a list of authorized users who can
communicate with your web service. If anyone wants to talk to your web service then he
has to register himself in your system as an authorized user. Here comes the need for
state management in web services. Since if an authorized entity wants to talk with your
web service then how can you maintain its state that how many times he has talked with

______________________________________________________________________________________
21
your web service, or if he has tried to do some kind of fraud or performed any kind of
illegal action. If you have been managing its state then you can block him and put it in
your block list. Since to do this you need statistics about him and without managing its
state you can not generate a report which describes his statistics so you can find who is
doing a fear business with you or someone tries to cheat you or wants to play an unfair
game. Securing web service is another topic which is beyond the scope of this study but
we will see that what is the importance of managing state and how can we manage state
in web service environment.
2.4.2 ebXML Registries
The ebXML standard was created by OASIS. The main aim behind ebXML was to
enable business applications exchange data in uniform format and to enable intelligent
business processes using XML. ebXML was developed as a mechanism for XML-based
business language since XML by itself does not provide semantics to solve
interoperability problems. In short, ebXML provides a common way for businesses to
quickly and dynamically perform business transactions based on common business
practices [1]. Figure 2.7 shows an example of ebXML architecture in use. In the diagram,
company business process information and implementation details are found in the
ebXML registry and businesses can do business transactions after they agree on trading
arrangements. Information that can be described and discovered in ebXML architecture
includes the following [1]:
 Business processes and components described in XML
 Capabilities of a trading partner
 Trading partner agreements between companies

______________________________________________________________________________________
22
Figure 2.7 An ebXML architecture in use. [1]
Understanding Web Services
The spirit of the ebXML architecture is the ebXML registry, which is the system that is
used to store and discover this information. The ebXML registry contains domain-
specific semantics for B2B. These domain-specific semantics are the product of
agreement on many business technologies and protocols. Simply ebXML could be
described as the start of a domain specific semantic Web. The focus of ebXML was not
initially on Web services, but it now uses SOAP as its message format. Therefore, many
believe that ebXML will have a large role in the future of Web services. Unlike UDDI,
ebXML is a standard. The ebXML standard does have support from many businesses, but
the most influential companies in Web services, IBM and Microsoft, would like to see
UDDI succeed as a registry for business information. However, it is possible that the two
technologies can complement each other, and ebXML could succeed in the B2B market,
while private UDDI registries succeed in the EAI market in the short term.

______________________________________________________________________________________
23
Chapter 3
Security Problem
When all the past distributed models were being implemented, one technology, security,
always seemed to be tackled last. The idea was to get the model working first, and then
worry about security. Inevitably, this resulted in poorly performing and difficult-to-use
security.
Web Services are a promising solution to an age-old need: fast and flexible information
sharing among people and businesses that promises tremendous benefits in terms of
productivity, efficiency, and accuracy. Web Services enable access to data that has
previously been locked within corporate networks and accessible only by using
specialized software. Along with the benefit, web services also present daunting
challenges relating to privacy and security. In exposing critical business functions to the
Internet, Web Services can expose valuable corporate data, applications, and systems to a
variety of external threats and sensitive and private data can be exposed to people who
are not supposed to see it. To secure this data, it is not sufficient to limit Web Services
security to company’s firewall. In world of electronic commerce, customers, remote
employees, suppliers, and at times even competitors, are all invited into the inner study of
computing system. Consequently, distributed security using the Web Services paradigm
requires end-to-end security—a service request is made, which goes through the firewall,
into application servers and applications at the heart of your corporate network, to the
persistent store of your sensitive data in the back-office [7].
Given the potential risks, security must be a central focus of any Web Services
implementation. Just as IT organizations are turning to proven Enterprise Application
Integration (EAI) [8] architectures to address systems integration issues, they can take
advantage of new Enterprise Application Security Integration (EASI) [8] architectures
that enable end-to-end integration of scalable, best-of-breed security technologies for
their Web Services.

______________________________________________________________________________________
24
What makes security for Web Services so challenging is the distributed, heterogeneous
nature of these services. Web Services technology is based on the interoperation of many
different software applications running on a variety of geographically dispersed systems
in a complex, multidomain environment via the Internet. The Extensible Markup
Language (XML); SOAP; Universal Description, Discovery, and Integration (UDDI);
Web Services Description Language (WSDL); and other protocols and mechanisms are
employed to enable platform-independent interaction across domains via the Internet.
3.1 What is Needed?
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 Services-based
applications that provide broad connectivity across a multitude of back-end systems.
These unified applications bring direct bottom-line benefits.
3.2 Goals of Security
Information security focuses on protecting valuable and sensitive enterprise data. To
secure information assets, organizations must provide availability to users, while barring
unauthorized access. In general, secure systems must provide the following protections
[8]:
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.

______________________________________________________________________________________
25
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 (non-repudiation).
Availability. Ensure uninterrupted service to authorized users. Service interruptions can
be either accidental or maliciously caused by denial-of-service attacks.
Security should be an integral part of Web Service design and implementation to provide
above four key protections.
3.3 Need for Security
Many system architects and developers are used 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 result, security is becoming an
important design issue for any e-business software component. The scope of Web
Services security is so broad. There are many examples that drive security needs [8]:
E-commerce sites on the Internet. These rely on credit card authorization services from
an outside company. A relationship between an e-commerce company and a credit card
service depends on 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 service based on existing
sales. Customer relationship management allows the enterprise to provide consistent
customer support across many different services.
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

______________________________________________________________________________________
26
the enterprises contain highly proprietary data that must be protected from outside
snooping.
In these examples, one enterprise can expose another organization to increased security
risk. For example, a partner can without intention expose your business to a security
attack by providing its customers access to your business resources. As a result, security
risk is so high for an organization.
3.3 Risk Management
A large middle ground exists of risk management between the options of avoiding e-
business applications based on Web Services altogether, launching unprotected systems,
or burdening every application with prohibitively costly and user-unfriendly security
measures. The risk-management aims to control risk, if not eliminated [9]. Risk
management is a precise 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 valid 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.
Different Web Services users have different concerns like, ISP’s primarily concern is
availability, hospital administrator requires data integrity, banker is cautious about
accountability, and the military officer worries about confidentiality [8].
The challenge is to implement security in a way that meets business needs cost
effectively 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

______________________________________________________________________________________
27
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.
3.3 Security: A Serious Concern
Information security is a serious concern for most businesses. Even though the reporting
of computer-based crime is irregular because companies fear negative publicity and
continued attacks, the trend is quite clear: Information security attacks continue to be a
real threat to businesses.
Threats to businesses result from both internal and external attacks. A large percent of
businesses detected insider attacks by trusted corporate users. 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. 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 [8]. 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. Because of the continuing threat, many businesses are increasing
their spending on security; large corporations are increasing their spending the most. It
has been seen organizations address security using a fragmented, inefficient approach, in
which various corporate divisions each build their own ad hoc security solutions. Security
system implemented gradually can be worse than no security at all because they believe

______________________________________________________________________________________
28
mistakenly that the system is secure, and there is redundant spending across the
organization, and solutions are not scalable and interoperable, and have high
maintenance, training and administration costs [8].
Applying security products without thinking about how they all fit together clearly does
not work. 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.
3.3 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.
3.3 Requirements for Web Services Security
There are some core security services that are fundamental to end-to-end application
security across multitier applications, which are as follows [9]:
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

______________________________________________________________________________________
29
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. Non-repudiation provides certain 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 reliable and provided with enough assurance. That is, there
must be confidence that security services have been implemented correctly, reliably, and
without relying on the secrecy of proprietary mechanisms.
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
cannot be achieved easily when one considers the range of systems, applications, and
business processes involved in a typical Web Services transaction—and when 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 [9]. This facility is used to limit the set of users who may either access or
update Web Services directory entries, and can be centrally managed.

______________________________________________________________________________________
30
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 authenticate again each time his/her request crosses from
one tier to another [9]. 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 layer
and domains in the Web Services world [9]. Flexible ways to create, pass, and establish
security contexts are needed for end-to-end security in a Web Services environment.

______________________________________________________________________________________
31
Chapter 4
Enterprise Application Security Integration
To solve the difficult issue of securely connecting Web servers to back-office data stores,
there is a concept of end-to-end Enterprise Application Security Integration (EASI).
EASI is a special case of EAI [8].
EAI is a technique for unifying many different applications by using a common
middleware infrastructure. EAI provides an application bus that allows every application
to communicate with others via a common generic interface. Without EAI, an application
would need a separate interface for every other application, thus causing too many
connections between applications. EAI allows application development to scale to a large
number of interchangeable components.
Integration of end-to-end security requires EAI techniques. Many different security
technologies are used in the front, middle, and back-office layers. Typically, these
security technologies do not interoperate easily. As a result, a separate ad hoc interface to
connect one security technology to another causes again too many connections between
security technologies [9].
EASI provides a common security framework to integrate many different security
solutions. We use Web Services security to bridge the security gap between front and
back-office security. EASI enables new security technologies in each tier to be added
without affecting the business applications.
4.1 EASI Requirements
A key issue in enterprise security architectures is the ability to support end-to-end
security across many application components. End-to-end security is the ability to ensure
that data access is properly protected over the entire path of requests and replies as they
travel through the system. The scope of end-to-end security begins with the person

______________________________________________________________________________________
32
accessing a Web browser or other client program, continues through the business
components of the middle tier, and ends at the data store on the back-office legacy
system. The path may travel through both public and private networks with varying
degrees of protection. In the enterprise architecture shown in Figure 4.1, a user accesses
an application in the presentation layer (for example, a Web browser client sends requests
to a Web server), which communicates to mid-tier business components (such as Web
Service enabled application servers) [10]. Frequently, the client request is transmitted
through a complex multitier business components running on a variety of platforms. The
request finally makes it to one or more back-office systems, which access persistent data
stores on behalf of the user, process the request, and return the appropriate results.
To provide end-to-end security, each link in the chain of requests and replies must be
properly protected: from the initiating client, through mid-tier business components, to
the back-office systems, and then back again to the client. There are three security tiers
that make up any end-to-end enterprise security solution [10]:
Perimeter security technologies. Used between the client and the Web server. Perimeter
security enforces protection for customer, partner, and employee access to corporate
resources. Perimeter security primarily protects against external attackers, such as
hackers.
Mid-tier security technologies. Used between the mid-tier business components. Mid-
tier security focuses primarily on protecting against insider attacks, but also provides
another layer of protection against external attackers.
Back-office security technologies. Address the protection of databases and operating-
system-specific back-end systems, such as mainframe, Unix, and Windows server
platforms.

______________________________________________________________________________________
33
4.2 EASI Solution
EASI solutions integrate security technologies across the front, middle, and back-office
security tiers [10]. An EASI solution first and foremost consists of a security framework,
which describes a collection of security service interfaces that may be implemented by an
evolving set of security products.
In addition to the framework, an EASI solution also contains the software and hardware
technologies for securing e-business components.
Finally, an EASI solution contains integration techniques, such as bridges, wrappers, and
interceptors, that developers can use to plug security technologies into a middleware
environment [10]. To hook together different security technologies, EASI must solve a
key problem: defining a secure association between clients and targets that establishes a
common security context. The security context, which contains a user’s identity and other
security attributes, must be transferred across the system to a target application. A user’s
identity and security attributes form the basis for authorization decisions and audit events,
and must be protected as they are transmitted between front, middle, and back-office
tiers, as shown in Figure 4.1. Because each technology in these tiers represents and
protects a user’s security information differently, integration of the security context can
be a rather difficult problem.
To get a mix approach of different security technologies to interact with one another, the
organization for the Advancement of Structured Information Standards (OASIS) is
defining standards called WS-Security [11] and SAML [12] to address this issue. WS-
Security defines a standard way to attach security information to SOAP messages, while
SAML defines a format for exchanging authentication, authorization, and attribute
assertions. The combination of these two specifications provides a description of the
security context that can be passed across the tiers of architecture. WS-Security and
SAML together are a standards-based approach for expressing the security context that is
not tied to any particular vendor’s application environment or security product. Designed

______________________________________________________________________________________
34
specifically for distributed security environments, WS-Security and SAML are important
building blocks for any Web Services security framework.
Figure 4.1. Key e-business challenge: end-to-end EASI [10].
4.3 EASI Framework
The EASI framework specifies the interactions among the security services and the Web
Services components that use those security services. By using common interfaces, it’s
possible to add new security technology solutions without making big changes to the
existing framework. In this way, the EASI framework supports plug-ins for new security
technologies. Key aspects of the framework are shown in Figure 4.2.
Applications
The security framework provides enterprise security services for presentation
components, business logic components, and back-office data stores. The framework
supports security mechanisms that enforce security on behalf of security-aware and
security-unaware applications [10].
Security-aware application. An application that uses security Application Programming
Interfaces (APIs) to access and validate the security policies that apply to it. Security-
aware applications may directly access security functions that enable the applications to

______________________________________________________________________________________
35
perform additional security checks and fully exploit the capabilities of the security
infrastructure.
Figure 4.2. EASI framework [10].
Security-unaware application. An application that does not explicitly call security
services, but is still secured by the supporting environment. Security is typically enforced
for security-unaware applications by using interceptors, which transparently call the
underlying security APIs on behalf of the application. This approach reduces the burden
on application developers to implement security logic within applications and lessens the
chance of security flaws being introduced.
Other applications, called security self-reliant applications, do not use any of the security
services provided by the framework. A security self-reliant application may not use the
security services for two reasons: because it has no security-relevant functionality and
thus does not need to be secured or because it uses separate independent security
functions that are not part of the defined EASI security framework.

______________________________________________________________________________________
36
APIs
The framework security APIs are called explicitly by security-aware applications and
implicitly by security-unaware applications via interceptors. Security APIs provide
interfaces for access to the framework security services. The framework supports
standard, custom, and vendor security APIs [10].
Standard security APIs. We encourage support for APIs based on open standards or
industry standards. These standards should be used whenever possible because they are
likely to provide the most stability and the most portability across many different
vendors’ products.
Custom security APIs. Custom APIs may be implemented when an enterprise’s needs
cannot be met by existing standard APIs. Custom APIs are required especially when an
enterprise uses a security service that is tailored to its business, for example, a custom-
rule-based entitlements engine developed internally by an investment bank.
Vendor security APIs. As a last resort, vendor-specific proprietary APIs may be used
where open standards have not yet been defined. We recommend avoiding the use of
proprietary security APIs in applications if at all possible. Proprietary APIs make it very
difficult for the developer or administrator to switch security products. Although vendors
may think this is a great idea, we believe that security technology is changing much too
rapidly for an enterprise to be confined to any one product. As an alternative, we
recommend wrapping a vendor’s proprietary API with a standard or custom API.
Core Security Services
The next layer of the security framework provides core security services enabling end-to-
end application security across multitier applications. Each of the security services
defines a wrapper that sits between the security APIs and the security products. The
security services wrappers serve to isolate applications from the underlying security
products. This allows one to switch security products, if the need arises, by simply

______________________________________________________________________________________
37
creating a new wrapper, without affecting application code. The key security services are
authentication, authorization, cryptography, accountability, and security administration.
Framework Security Facilities
The framework provides general security facilities that support the core security services.
The framework security facilities include the profile manager, security association, and
proxy services [10].
Profile manager. Provides a general facility for persistent storage of user and application
profile and security policy data that can be accessed by other framework services.
Security association. Handles the principal’s security credentials and controls how they
propagate. During a communication between any two client and target application
components, the security association establishes the trust in each party’s credentials and
creates the security context that will be used when protecting requests and responses in
transit between the client and the target. The security association controls the use of
delegation, which allows an intermediate server to use the credentials of an initiating
principal so that the server may act on behalf of the principal.
Security proxy services. Provide interoperability between different security technology
domains by acting as a server in the client’s technology domain and a client in the
target’s domain.
Security Products
Implementation of the framework generally requires several security technology products
that collectively constitute the enterprise security services. Examples of such required
security products include firewalls, Web authentication/authorization products, Web
Service and component authentication/authorization products, cryptographic products,
and directory services.

______________________________________________________________________________________
38
4.4 EASI Benefits
The benefits of using a framework to address enterprise application security integration
are clear. The approach focuses on standards, which are the best way to maintain Web
Service application portability and interoperability in the long run. Products and
technologies will come and go, but generally accepted security standards for fundamental
security services will be much more stable. A standards-based set of security APIs allows
you to evolve security products over time without needing to rewrite your applications.
Designing user applications for evolving security products is important because user
business requirements and new security technologies will continue to be a moving target.
One might choose a great product that satisfies the needs for the present, but one can
probably want to change the product in the future.
Having a security framework also means that everything does not need to be
implemented at once. The framework allows user to start small by selecting the security
services user needs and building more sophisticated security functionality when and if it’s
required. The framework provides a roadmap for security architecture, helping to guide
on how to choose products and technologies that match the needs over time [10].
Finally, the framework puts the security focus where it should be—on building a
common infrastructure that can be shared across the enterprise. Custom-built security that
is hand-coded within applications is expensive to implement and maintain and is likely to
have more security vulnerabilities [10]. A single security infrastructure with APIs that
can be used by all of the applications avoids multiple, duplicate definitions of users,
security attributes, and other policies. User can focus his limited time and money on
building a few critical interoperable security technologies rather than coping with a mass
of unrelated security products that will never work together.

______________________________________________________________________________________
39
Conclusion
This study tried to assess different approaches toward building secure web services
architecture, and tried to highlight some security concerns. In general, it is recommended
that web services be designed according to the principles of enterprise application
security architecture. However, it is sometimes desirable to build services capable of
referencing each other, which may lead to a finer-grained, secure services design. When
building a new service, it is worth considering carefully the pros and cons of all design
styles, and gathers the requirements of target environment and goal of the system, which
can result in a better integration solution for a targeted domain.

______________________________________________________________________________________
40
REFERENCES
[1] Micheal C. Daconta, Leo J. Orbst, Kevin T. Smith. Chapter 4: Understanding Web
Services. The Semantic Web: A Guide to the Future of XML, Web Services, and
Knowledge Management. Wiley Publication, Inc. 2003
[2] Extensible Markup Language (XML) – “http://www.w3.org/TR/xml/” Retrieved on
January 18, 2007
[3] Fielding, Gettys, Mogul, et al. Hypertext Transfer Protocol – HTTP/1.1 RFC 2616,
Internet Society, 1999. "http://www.w3.org/Protocols/rfc2616/rfc2616.html" Retrieved
on February 5, 2006
[4] Simple Object Access Protocol (SOAP) – “http://www.w3.org/TR/SOAP” Retrieved
on February 12, 2006
[5] Francisco Curbera, Matthew Duftler, Rania Khalaf, William Nagy, Nirmal Mukhi,
and Sanjiva Weerawarana. Unraveling the Web Services Web An Introduction to SOAP,
WSDL, and UDDI, pages 86-93, IEEE Internet Computing
[6] Doug Tidwell, James Snell, Pavel Kulchenko. Chapter 2: Introducing SOAP.
Programming Web Services with SOAP. O'Reilly December 2001
[7] Bret Hartman, Donald J. Flin, Konstantin Beznosov, Shirley Kawamoto. Introduction.
Mastering Web Services Security. Wiley Publishing Inc. 2003
[8] Bret Hartman, Donald J. Flin, Konstantin Beznosov, Shirley Kawamoto. Security as
Enabler for Web Services Application: Chapter 1: Overview of Web Service Security.
Mastering Web Services Security. Wiley Publishing Inc. 2003

______________________________________________________________________________________
41
[9] Bret Hartman, Donald J. Flin, Konstantin Beznosov, Shirley Kawamoto. Securing
Web Services: Chapter 1: Overview of Web Service Security. Mastering Web Services
Security. Wiley Publishing Inc. 2003
[10] Bret Hartman, Donald J. Flin, Konstantin Beznosov, Shirley Kawamoto. Unifying
Web Services Security: Chapter 1: Overview of Web Service Security. Mastering Web
Services Security. Wiley Publishing Inc. 2003
[11] Web Service Security (WS_Security) – “http://www.oasis-
open.org/committees/tc_home.php?wg_abbrev=wss” Retrieved on March 8, 2007
[12] Security Assertion Markup Language (SAML) – “http://www.oasis-
open.org/committees/tc_home.php?wg_abbrev=security” Retrieved on March 8, 2007

Web Services Security - Full Report

Recommended

Recommended

More Related Content

Similar to Web Services Security - Full Report

Similar to Web Services Security - Full Report (20)

Web Services Security - Full Report