This document discusses security considerations for web services. It begins by defining key terms like web services, SOAP, WSDL, UDDI, and ebXML. It then discusses the goals of security like confidentiality, integrity, accountability and availability. Next, it covers requirements for web services security like authentication, authorization, cryptography, and accountability. It introduces the concept of Enterprise Application Security Integration (EASI) to provide a common security framework across different tiers. EASI requires perimeter security between clients and web servers, mid-tier security between application components, and back-office security for databases. The document concludes that web services should be designed according to enterprise application security architecture principles.

1. 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,

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

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

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

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