Web Services Security

Muhammad Jawaid Shamshad (m_jawaids@yahoo.com), Naeem Janjua

SZABIST Karachi, Pakistan

Abstract: Web Services have great potential, but 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.

Keywords: Web Services, Security, SOAP, WSDL, UDDI,

ebXml

1. INTRODUCTION

Before we can define the means by which Web

services can be made secure, we need to explain a few

terms and concepts.

1.1 Web Services

Authors of the “Semantic Web” [1] defines web

services as “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.”

The definition expresses the main point that web

services are software applications like other usual software

applications which performs some specific tasks

depending on their implementation. The main focus of

web services is interoperability. Web services use XML [2]

as the syntax of their message and use HTTP [3] to

transfer that message. The message is basically a Simple

Object Access Protocol (SOAP [4]) envelop which is in

XML format.

1.2 SOAP

Simple Object Access Protocol (SOAP) was created

by Microsoft, Developmentor, IBM, Lotus, and UserLand.

W3C defines SOAP as “a lightweight protocol for

exchange of information in a decentralized, distributed

environment.” [4]. SOAP is an XML-based protocol for

messaging and remote procedure calls (RPCs). 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

encapsulated in SOAP envelop. The envelope features

child elements that contain the message header and body

elements [5]. SOAP header contains the Meta information

and the body contains the actual message or remote

procedure call (RPC) in XML syntax. This is graphically

depicted in Figure 1.

Figure 1. The SOAP message structure [6].

1.3 WSDL

Web Service Definition Language (WSDL) [5] is the

way we describe the communication details and the

application-specific messages that can be sent in SOAP.

The W3C defines WSDL as “an XML format for

describing network services as a set of endpoints operating

on messages containing either document-oriented or

procedure-oriented information”. WSDL, like SOAP, is

also in XML format and developed by IBM and Microsoft.

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.

1.4 Discovering Web Services

Some kind of registry is needed to maintain a list of

web services and their feature so anyone can search

desired web service in that registry and communicate with

it. There are two major technologies for this purpose. One

is UDDI, and second is ebXML registries.

1.4.1 UDDI

UDDI (Universal Description, Discovery, and

Integration) was introduced in 2000 by Ariba, Microsoft,

and IBM to facilitate the discovery of business processes.

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]. In UDDI

organizations register their information about their web

services and 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.

Applications can search for that information in the registry

and call there desired web service.

1.4.2 ebXML Registries

The ebXML standard was created by OASIS in 1999.

The main aim behind ebXML it to provide a common way

for businesses to quickly and dynamically perform

business transactions based on common business practices

[1]. Figure 2 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.

Figure 2. An ebXML architecture in use [1].

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 [7]:

Confidentiality. Safeguard user privacy and prevent the

theft of enterprise information both stored and in transit.

Integrity. Ensure that electronic transactions and data

resources are not tampered with at any point, either

accidentally or maliciously.

Accountability. Detect attacks in progress or trace any

damage from successful attacks (security auditing and

intrusion detection). Prevent system users from later

denying completed transactions (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. NEED FOR SECURITY

Web Services change the risk levels associated with

deploying software because of the increased ability to

access data, and as a result, security is an important design

issue for any e-business software component. Following

are some examples that drive security needs [8]:

E-commerce sites on the Internet. These rely on credit

card authorization services from an outside company.

Cross-selling and customer relationship management.

This relies on customer information being shared across

many lines of business within an enterprise.

Supply chain management. This requires continuing

communication among all of the suppliers in a

manufacturing chain. The transactions describing the

supply chain that are exchanged among the enterprises

contain highly proprietary data.

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.

4. 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

encoding data into an unintelligible form with a reversible

algorithm, which allows the holder of the decryption key

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.

5. EASI

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 provides a common security framework to

integrate many different security solutions. EASI enables

new security technologies in each tier to be added without

affecting the business applications.

5.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. 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.

5.2 EASI Solution

EASI solutions integrate security technologies across

the front, middle, and back-office security tiers [10]. An

EASI solution consists of a security framework, which

describes a collection of security service interfaces that

may be implemented by an evolving set of security

products.

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]. 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 3.

Figure 3. End-to-end EASI [10].

5.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.

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].

Other applications, called security self-reliant

applications, do not use any of the security services

provided by the framework.

The framework security APIs are called explicitly by

security-aware applications and implicitly by security-

unaware applications via interceptors. The framework

supports standard, custom, and vendor security APIs [10].

Figure 4. EASI Framework [10].

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 creating a new wrapper, without

affecting application code. The key security services are

authentication, authorization, cryptography, accountability,

and security administration.

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].

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.

5.4 EASI Benefits

The approach focuses on standards, which are the best

way to maintain Web Service application portability and

interoperability in the long run. 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.

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 [10].

Finally, the framework puts the security focus on

building a common infrastructure that can be shared across

the enterprise [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.

3. CONCLUSIONS

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.

ACKNOWLEDGMENT

The author thanks Naeem Janjua who gave precious

advice in conducting this study.

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

September 8, 2006.

[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 September 8, 2006.

[4] Simple Object Access Protocol (SOAP) –

“http://www.w3.org/TR/SOAP” Retrieved on

September 8, 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

[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