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

Documents

security best practice

independent study report

era of technology

advisor sir naeem janjua

fresh way

faculty of computer

table of contents chapter

degree of master