Web Services Security: is the problem solved?

Carlos Gutiérrez

, Eduardo Fernández-Medina

and Mario Piattini

(1) Sistemas Técnicos de Loterías del Estado.

Calle Manuel Tovar 9, 28034, Madrid. (SPAIN).

(2) Alarcos Research Group. Universidad de Castilla-La Mancha.

Paseo de la Universidad 4, 13071, Ciudad Real. (SPAIN)

Abstract. During the past years significant standardization work in web

services technology has been made. As a consequence of these initial efforts,

web services foundational stable specifications have already been delivered.

Now, it is time for the industry to standardize and address the security issues

that have risen from this paradigm. Great activity is being carried out on this

subject. This article demonstrates, however, that a lot of work needs to be done

in web services security standardization. It explains the new web services

security threats and mentions the main initiatives and their respective

specifications that try to solve them. Unaddressed security issues for each

specification are stated. In addition, current general security concerns are

detailed and a general solution is proposed.

1 Introduction

Recently web services technology has reached such a level of maturity that it has

evolved from being a promising technology to becoming a reality on which IT

departments are basing their operations to achieve a direct alignment with the

business operations that they support [9]. In fact, based on the most recent reports

from IDC[17], approximately 3300 web services-based technology projects were

deployed all over North America in 2002 and it is expected that the expenses will

approach $3 billion in 2003. This seems to be a logical consequence of the numerous

advantages offered by the web services paradigm:

• Standard-based middleware technology.

• Business services high reusability level.

• Easy business legacy systems leverage.

• Integration between heterogeneous systems.

Due to these immediate benefits, most IT departments are implementing this

technology with the high-priority objective of making them operable leaving aside –

at least until later stages – the problems related to security. In general, the industry is

still reticent to incorporate this technology due to the low understanding that they

Rahmani H. (2004).

Promiscuous Mode Detection Platform.

In Proceedings of the 2nd International Workshop on Security in Information Systems, pages 293-304

DOI: 10.5220/0002684602930304

 SciTePress

have of the security risks involved, and the false belief that they will have to make a

costly reinvestment in their security infrastructures.

Web services as distributed, decentralized systems that provide well-defined

services to certain (or not) predetermined clients, must be concerned with typical

security problems common to the communication paradigm, through a compromised

channel, between two or more parties.

2 Main Web Services Security Issues

The following section describes some of the major security issues that web services

technologies must address:

Authentication: any web service that participates in an interaction may be required

to provide authentication credentials by the other party. When certain service A

makes a request for a service to a service B, the latter may require credentials along

with a demonstration of its ownership (e.g.: a pair username/password or a X.509v3

certificate).

Authorization: Web services should include mechanisms that allow them to control

the access to the services being offered. They should be able to determine who and

how can do what and how on their resources.

Confidentiality: Keeping the information exchanged among web services nodes

secret is another of the main properties that should be guaranteed in order to consider

the channel secure. Confidentiality is achieved thanks to ciphering techniques

Integrity: This property guarantees that the information received by a web service

remains the same as the information that was sent from the client. A simple checksum

might offer integrity when accidental changes are made in the data.

Non-repudiation: In the web services world, it is necessary to be able to prove that

a client utilized a service (requester non-repudiation) and that the service processed

the client request (provider non-repudiation). This security issue is covered by means

of digital signatures.

Availability: The need to take care of the availability aspects for preventing Denial-

of-Service attacks or to arrange redundancy systems is a crucial point in web services

technology. Above all, in those scenarios in which the services provide critical

services: real-time services, Certification Revocation Lists services, etc.

End-to-end security: network topologies require end-to-end security to be

maintained all across the intermediaries in the message's path. "When data is received

and forwarded on by an intermediary beyond the transport layer, both the integrity of

data and any security information that flows with it maybe lost. This forces any

upstream message processors to rely on the security evaluations made by previous

intermediaries and to completely trust their handling of the content of messages" [14].

Up to this point, we have briefly reviewed the typical security problems tightly

related to distribute computing systems. Web services must address both these,

inherited from the distributed computing classical scheme, and, in addition, those

arising from the new threats created by its own nature. Some of these new threats are:

• Diversity and very high number of standard specifications that do not facilitate a

clear vision of the problematic and its solutions.

294

• The current draft state in which majority of the security specifications are found.

• The Internet publication of a complete and well-documented interface to back-

office data and company's business logic.

• New XML standard formats needed to structure the security data.

• Application-level, end-to-end and just-one-context-security communications.

• Interoperability of the requirements and on-line security elements

• Audit and automatic and intelligent contingency processes aimed at being

machine-to-machine interactions not controlled by humans.

• A complex dependency network that can lead to the execution of a business

process depending on an unknown web services number.

• On-line availability management in critical business processes.

The remainder of this article is divided into 5 parts. In the first one, a brief review

of the core specifications that support the technology at hand is made. In the second

section, core security web services specifications are explained, and unresolved issues

not yet addressed by them are described. In the third and fourth parts, the main

initiatives are introduced as well as the specifications related to the security that they

are involved in. The fifth and last section, show how variety and, to a certain extent

uncontrolled, specifications development and initiatives are already causing collisions

among solutions to similar security problems.

3 Web Services Core Standards

In this section, we will take a look at the four fundamental standards involved in the

creation of operational web services.

Figure 1 outlines the most important security specifications under development. They

are grouped as following:

• Core: web services foundational specifications. These are the standards web

services building are based on.

• Core Security: standards that provides the XML low-level security primitives

such as ciphering and signing.

• WS-Security: family of specification developed by Microsoft and IBM

which are under OASIS standardization process

• OASIS: security specifications developed by OASIS standards body.

• Liberty Alliance Project: represents the group of specifications developed in

the Liberty Alliance Project.

295

SOAP

lat es t St ableRelease = 1. 2

(f rom Specif ic at ion)

<<specif icati on>>

WSDL

lat es t StableRelease = 1. 1

(f rom Specif ic at ion)

<<spe ci fic ati on>>

W 3C Canonical XML

lat est St ableRelease = 1. 0

(from Specification)

<<specif icati on>>

XM L Key Management Sy s t em

lat est St ableRelease = 2. 0

(f rom XML Key Management System)

<<specif icati on>>

XM L-Signat ure XPat h F ilt er

lat es t StableRelease = 1. 0

(f rom Specif ic at ion)

XM L Dec rypt ion T ransf orm

(from Specification)

<<speci ficati on>>

CoreSecurity

Core

XML

lat es t St ableRelease = 1. 0

(from XML)

<<specif icati on>>

WS-Secur ity

lat es t StableRelease = 1.1

(from WS-Security)

<<spe cif ic ati on>>

WS-Trust

lat es t StableRelease = Draf t

(from WS-Security)

<<speci ficati on>>

WS-Policy

lat est St ableRelease = Draf t

(from WS-Security)

<<specif icati on>>

WS-Privacy

lat est St ableRelease = Draf t

(from WS-Security)

<<specif icati on>>

W S-PolicyAs sert ions

lat es t StableRelease = Draf t

(from Policy)

<<speci ficati on>>

W S -Securit y Policy

lat es t St ableRelease = Draf t

(from Policy)

<<spe cif ic ati on>>

W S-PolicyAt t achment

lat es t StableRelease = Draf t

(from Policy)

<<spe ci fic ati on>>

WS-Secur eConvers at ion

lat es t StableRelease = Draf t

(f rom W S_SecureConversat ion)

<<spe ci fic ati on>>

W S-F ederat ion

lat est St ableRelease = Draf t

(f rom W S_F ederat ion)

<<specif icati on>>

WS-Aut hor izat ion

lat est St ableRelease = Draf t

(from WS-Security)

<<specif icati on>>

WS-Security

XML Encryption

lat es t StableRelease = 1. 0

(from Specification)

<<spe ci fic ati on>>

XML Digital Signat ure

lat es t StableRelease = 1. 0

(f rom Specif ication)

<<speci ficati on>>

XACML

lat es t StableRelease = 1. 0

(f rom Specif ic at ion)

<<spe ci fic ati on>>

SAML

lat est St ableRelease = 1. 1

(from Specification)

<<specif icati on>>

OASIS

Liberty Alliance Project

UDDI

lat es t StableRelease = 3. 0. 1

(f rom Spec if icat ion)

<<spe ci fic ati on>>

Fig. 1. Current security standards grouped by the organizations responsible for its

standardization process

“Basic services, their descriptions, and basic operations (publication, discovery,

selection, and binding) that produce or utilize such descriptions constitute the SOA

foundation” [20]. Web services are built on an architecture SOA basis. In fact, web

services architecture is a SOA architecture instantiation [7]. For that reason, the

fundamental characteristics described by SOA are the ones that have initially headed

the major efforts in the industry standards development process. The core web

services specifications are: XML [24], SOAP [20], WSDL [16], and UDDI [1].

These specifications have been broadly adopted by the industry, constitute the

basic building blocks on which web services are being designed and implemented.

The bad news is that these four operative services specifications allow the creation of

web services but they do not say anything about how to secure them. What's more,

they themselves contain security questions that must be answered:

• XML and SOAP: these specifications do not say anything about how to obtain

integrity, confidentiality and authenticity of the information that they represent and

transport respectively.

• UDDI and WSDL: should answer questions like: Is the UDDI registry located in a

trustworthy location? How can we be sure that the published data have not been

maliciously manipulated? Was the data published by the business it is supposed to

have been? Can we rely on the business that published the services? Are the

296

services available at any moment? Can we trust the transactions that are produced

from the execution of the business services? As we can notice from all these

questions, an in-depth analysis of the security problems that an UDDI and WSDL

architecture implies is needed [5]. Despite all these drawbacks, these standards

have evolved and matured and the industry has adopted and implemented most of

them.

At this point, the main web services standardization initiatives are the World Wide

Web Consortium (W3C) and the Organization for the Advancement of Structured

Information Standards (OASIS). Both consortiums are trying to standardize their

vision, security included, of what the web services should be and should contribute to

the WWW world. This parallelism is causing the existence of specifications

developed by both groups that resolve similar problems. As is expressed by IBM and

Microsoft [10] "We note that other organizations such as the IETF and ebXML are

tackling a related set of problems, and we are pleased there are already formal liaisons

between the W3C XML Protocol Working group and its counterparts in both ebXML

and IETF".

All the involved parts will have to make efforts to unify in the future with the

purpose of integrating their visions and standards and thus, define a common and

global framework.

4 Core Web Services Security Standards

The W3C consortium is responsible for the development of the following XML

technology standards: XML Encryption; XML Digital Signature; XML Key

Management System.

4.1

XML Encryption

W3C XML Encryption [15] is a Proposed since 2002. It provides a model for

encryption, decryption and representation of: full XML documents; single XML

elements (and all descendants) in an XML document; contents of an XML element

(some or all of its children including all its descendants) in an XML document; and

arbitrary binary content outside an XML document.

XML Encryption solves the problem of confidentiality of SOAP messages

exchanged in web services. It describes the structure and syntaxes of the XML

elements, which represent encrypted information and it provides rules for

encrypting/decrypting an XML document (or parts of it).

The specification states that encrypted fragments of a document should be replaced

by XML elements specifically defined in the recommendation. In order to recover the

original information, a decryption process is also specified.

Web services use XML for delivering the necessary meta-information (SOAP

headers) and the payload. As a result, XML Encryption can be used for

encrypting/decrypting any fragment or logical part of a XML message. XML

Encryption does not specify how to encrypt SOAP messages generated by web

services. This task is delegated to higher-level specifications that would define rules

for using this primitive within the information exchange context. XML Encryption

297

also describes how to encrypt already encrypted content (super-encryption) and

provides a mechanism for encrypting the keys used in the process.

Looking back at the beginning of this section, where a list is given of the data-

types that can be encrypted, we may miss the possibility of encrypting the tree nodes

without having to encrypt full sub-trees. Basically, the solution would consist of

extracting the wanted nodes from the original document, encrypt each of them and put

them in an encrypted nodes pool. The recipient will get the modified document and

the encrypted nodes pool, and it will be able to decrypt the nodes, which it is allowed

to see and put them back in place inside the document [12].

One of the implicit security problems associated to this specification is the explicit

declaration of the fragments that have been encrypted. According to the specification,

information is encrypted and replaced by XML elements containing the result and so,

analysis information attacks could be easily carried out on the output document.

Recursivity is also addressed, but no solution is given. Encrypted key A may need

encrypted key B, but B may also need A. XML Encryption recommends the use of ds:

namespace for these elements, which is where XML Digital Signature elements

belong to, instead of providing a different namespace, more like the WS-Security

family.

4.2

XML Digital Signature

XML Digital Signature [3] is a W3C recommendation since 2002, fruit of the joint

work between W3C and the IETF. It defines how to digitally sign XML content and

how to represent the resulting information according to an XML schema. Digital

signatures grant information integrity and non-repudiation. Thus, for example, an

entity cannot deny the authorship of a digitally signed bank transfer made through a

web service.

According to the XML Digital Signature specification, a digital signature can be

applied to any kind of digital content, including XML. It can be applied to the

contents of one or more resources. Enveloped signatures and enveloping signatures

exist. Both of them are applied over data contained within the same XML document

that carries the digital signature. Detached signatures which sign digital content not

contained within the same XML document also exist.

Signature creation and verification processes are defined by the specification. It is ,

like XML Encryption, technology independent, so additional mechanisms are needed

to define how it will be applied to web services message exchange.

Applications using this specification combined with encryption must deal with

some security related issues. The following rules are proposed:

• When the data are ciphered, any digest or signs on the data would have to be

ciphered as well so that it is prepared to anticipate guessing plaintext attacks.

• Use XML Decryption Transform transformation during the digital signature

verification process [2].

298

4.3 XML Key Management System

XML Key Management System [22]is a specification that has been subject to the

W3C standardization process that proposes an information format as well as the

necessary protocols to convert a Public-Key Infrastructure in a web service so that it

will be able to: Register public/private key pairs; locate public keys; validate keys;

revoke keys; and recover keys.

This way, the entire PKI is extended to the XML environment, thus allowing

delegation of trustworthy decisions to specialized systems. XKMS is presented as the

solution for the creation of a trustworthy service that offers all PKI subordinate

services, but without resolving the inherent issues of the infrastructure:

• How can a Certification Authority’s public key be known with total certainty?

¿Is the CA ascertained identity useful?

• Known issues with OIDs (Object Identifiers) for automatic processing and their

explosive and continuing growth.

• Since the global public key infrastructure is lacking a single world-recognized

certification authority, it is not clear how to equip the world in order to allow

two systems (ex. web services) that know nothing of each other to establish a

trustworthy relationship through a third party on the fly and with no previous

off-line communication.

5 Web services Security: Standards and Security Issues Already

Addressed

Now that we have reviewed the basic web services security standards and their related

security, we turn to detail the emerging technology and specifications that are based

on these standards.

First, we will briefly touch on the WS-* specifications, whose principal developers

are IBM and Microsoft. Secondly and thirdly, we will talk about the SAML and

XACML standards, which have already been delivered by the OASIS organization in

their initial versions, and whose objective is how to present information and the

security policy, respectively. Fourthly, we will briefly comment on the Liberty

Alliance project, which is lead by Sun Microsystems, and fifthly and lastly, we will

give a summary in matrix form showing all of the specifications that are covered in

this paper, noting those that have been delivered and those that are still in draft form.

5.1 WS-Security Family Specifications

IBM and Microsoft, together with other major companies, have defined a web

services security model that guarantees end-to-end communication security.

These companies are jointly elaborating a series of specifications that compose an

architecture, termed by Microsoft as Global XML Web Services Architecture [8], that

will lead the development in the web services industry so that different products can

inter-operate within a secured context. The center of these specifications is composed

by: WS-Addressing, WS-Coordination, WS-Inspection, WS-Policy, WS-Referral,

WS-ReliableMessaging, WS-Routing, WS-AtomicTransaction, and WS-Security.

299

We will focus our attention to the last specification: WS-Security. IBM, Microsoft,

and VeriSign developed and submitted to OASIS which is responsible of its

standardization process. WS-Security [21] “describes enhancements to SOAP

messaging to provide quality of protection through message integrity, message

confidentiality, and single message authentication. These mechanisms can be used to

accommodate a wide variety of security models and encryption technologies” .This is

the specification on which some additional specifications (some with publicized

versions) that cover all aspects of security in web services have based their definition.

WS-Security is placed at the base of the security specification pile. Its purpose is to

provide Quality of Protection to the integration, adding the following properties to

communication and messages: message integrity, confidentiality and simple

authentication of a message. WS-Security allows the easy incorporation of many

existing security models such as PKI and Kerberos.

Other specifications that directly relate to security issues such as WS-

SecurityPolicy, WS-Trust, WS-Privacy, WS-SecureConversation, WS-Authorization,

and WS-Federation are being developed based on WS-Security.

In the protocol stack and right on top of WS-Security, we find the WS-Policy

specifications (with its security attached WS-SecurityPolicy specification), WS-Trust

and WS-Privacy.

WS-Trust is another specification deserving mention due to its similarity with

XKMS. WS-Trust defines an XML schema as well as protocols that allow security

tokens to be accessed, validated and exchanged. However, this is not a new problem

since the XKMS specification already addresses it when the underlying security

infrastructure is PKI. Therefore, if we wish to extend a PKI as web service, ¿which of

the two standards should we use?

Another noteworthy specification is WS-Policy and its related specifications: WS-

SecurityPolicy, WS-PolicyAssertions, WS-PolicyAttachment. These specifications

define an XML syntax for defining web service policies (WS-Policy); a way to relate

policies to XML elements, UDDI entries or WSDL descriptors; a combination of

policy assertions of a general nature (WS-Policy-Assertions); and a combination of

policy assertions of a security nature (WS-SecurityPolicy).

5.2 SAML

Secure Assertion Mark-up Language [11] is an "OASIS Open Standard" specification

developed by OASIS and was delivered in its first version by 2002.

Basically, this specification defines a XML schema that allows trust assertions

(authentication, authorization o attribute) representation in XML and request/response

protocols to perform XML authentication, authorization and attribute assertion

requests.

However, SAML has not yet resolved all the problems related to interoperable

XML security-data transferences [13]. However it shows a significant progress. For

instance, SAML does not solve how the authentication evidence itself is transferred.

This issue has been addressed by WS-Security through its UsernameToken and

BinarySecurityToken security tokens definition. In addition, SAML does not define

the way to include SAML assertions within SOAP "wsse:Security" block headers

(defined by WS-Security specification). In August 2002, WS-Security specification

300

delivered the technical paper "The WS-Security Profile for XML-based Tokens" [23]

in order to solve this matter.

5.3 XACML

XACML [19] is another OASIS specification since February 2003 and its main

intention is to define an XML vocabulary for specifying the rules from which access

control decisions can be enforced.

XACML defines these access control rules depending on the requester

characteristics, communication protocol in use and the authentication mechanism

used. XACML is very similar, as far as the security problem it solves, with the policy

rules model and language defined by the previously studied WS-Policy family

specifications. This coincidence is another example of the unification effort proof that

an attempt will have to be made in the future to define a sole model and language

policy-related in the web services world. XACML defines a service architecture that

must be implemented by fully-fledged policy architectures:

5.4

Liberty Alliance Project

The Liberty Alliance Project [6], led by Sun Microsystems, and its purpose is to

define a standard federation framework that allows services like Single Sign-On.

Thus, the intention is to define an authentication distributed system that allows

intuitive and seamless business’ interactions. As we can see, this purpose is the same

as WS-Federation specification and Passport's .NET technology ones. Once again,

this is another example of the previously so-called overlap problem in web services

security solutions.

Table 1. Summary of the current web services standard development efforts grouped by topic.

Authentication

WS-Security, WS-Trust (draft), XKMS, SAML profiles

(request/response protocol for obtaining SAML assertions), Liberty

Alliance Project (SSO using extending SAML framework), WS-

Federation (SSO) (draft)

Authorization XACML (Policy-base authorization), WS-Authorization (draft)

Confidentiality XML Encryption, WS-Security (draft)

Integrity XML Digital Signature

Non-repudiation XML Digital Signature, WS-Security

Security policies WS-Policy + WS-SecurityPolicy (draft) , XACML

Trust authority

WS-Trust (draft)

XKMS

Security contexts/ keys

derivation

WS-SecureConversation

Delegation/Proxy WS-Trust (draft), Delegation has not been fully addressed yet.

Privacy WS-Privacy (draft)

Attribute mapping ??????

Reference security architecture ??????

Security methodology ??????

301

6 Issues to Be Solved

In spite of the amount of specifications that we have reviewed in this article, and

summarized in Figure 1, there are a lot of unresolved security issues that will have to

be addressed and standardized in the future:

1. A clear effort should exist from all entities involved in this technology in order to

unify their criteria and solutions. The explosion of specifications and concepts is

such that the learning curve may become unacceptable for the most of the IT

projects. As it has been demonstrated during this article, questions like knowing

whether the chosen solution is the best of all the possible ones or, if a solution has

been chosen, it will be long-term supported by the major industry companies, are

difficult to answer.

2. Another problem to be solved is attribute or role principal mapping among

different systems. Coherent access control decisions will be difficult to be made

when the same name of attributes or roles in both interacting web services are set.

For instance, certain set of attributes assigned to user A in system Y may have a

completely different meaning in other system B. System B should need to map the

attributes provided by user A to its own attributes types in order to be able to make

a coherent access decision. RBAC [4] together with a global attribute mapping

agreement maybe the way to reach a successful solution.

3. Nowadays, a methodology that accomplishes and consider all the possible security

issues and defines an organized development process that directs web services

deployments in all expected (and unexpected) scenarios does not exist. This

methodology should produce a distributed security framework. This framework

would address all the necessary security primitives (authentication, security policy

statements, confidentiality ...) and should be flexible enough as to allow primitive

implementation solutions replacements without affecting the overall performance

of the system. Thus, it should be able to define a framework where specialized

security modules maybe plugged in. For instance, it should allow us to replace a

WS-Trust security module for a XKMS module in a transparently way for the

client. As a first approach, and inspired by SUN JMX architecture, we would

design this framework by means of a security specialized microkernel creation in

such a way. This microkernel would have a central component with not specific

functionality beyond that as acting as socket where security modules can be

plugged in. Every security module would plug in the socket by means of a well-

known interface and would notice to the component about the security primitives it

provides. Any client security request will be intercepted by the central component

and then redirected to the correspondence security service. The response will be

brokered by the central component as well.

7 Conclusion

In this article, we have reviewed the current web services security specification and

initiatives and we have shown that its diversity is provoking an unclear vision of the

302

problem and their solutions. In addition, unaddressed security issues have been stated

overall and for each specification. The lack of a global standardization initiative is

causing that overlapping solutions to similar problems are being put forward. This

fact will require an extra effort in the future not only for the specifications to unify

and make themselves interoperable but for industry to adopt and implement them.

Therefore, solutions to topics like security policies, delegation, inter-business

principal attributes mapping and privacy are not yet addressed by delivered and stable

standards.

Acknowledgment

This research is part of the CALIPO project supported by Dirección General de

Investigación of the Ministerio de Ciencia y Tecnología (TIC2003-07804-C05-03).

References

1. UDDI Version 3.0.1 - UDDI Spec Technical Committee Specification 14 October 2003. See

http://uddi.org/pubs/uddi-v3.0.1-20031014.htm

2. Decryption Transform for XML Signature - W3C Recommendation 10 December 2002. See

http://www.w3.org/TR/2002/REC-xmlenc-decrypt-20021210

3. XMLDsig. XML-Signature Syntax and Processing- W3C Recommendation 12 February

2002. See http://www.w3.org/TR/xmldsig-core/

4. RBAC. Role-based Access Control - Draft 4 April 2003. See http://csrc.nist.gov/rbac/rbac-

std-ncits.pdf

5. Adams, C. and S. Boeyen (2002) UDDI and WSDL Extensions for Web Services: a security

framework. Proceedings of the ACM Workshop on XML Security. Fairfax, VA, USA.

6. Liberty Alliance Project. Introduction to the Liberty Alliance Identity Architecture. See

http://www.projectliberty.org/resources/whitepapers/LAP%20Identity%20Architecture%20

Whitepaper%20Final.pdf

7. WSAS. Web Services Architecture Specification - WC3 Working Draft 8 August 2003. See

http://www.w3.org/TR/2003/WD-ws-arch-20030808/

8. Box, D. (2002) Understanding GXA. See

http://msdn.microsoft.com/library/default.asp?url=/library/en-

us/dngxa/html/gloxmlws500.asp

9. Casati, F., E. Shan, U. Dayal and M.-C. Shan (2003) Business-Oriented Management of Web

Services. Communications of the ACM, Vol. 46, Nº 10, October 2003, pp. 25-28.

10. IBM and Microsoft. Web Services Framework. See http://www.w3.org/2001/03/WSWS-

popa/paper51

11. SAML. Assertions and Protocol for the OASIS 2 Security Assertion Markup Language 3

(SAML) V1.1. See http://www.oasis-open.org/committees/download.php/3406/oasis-sstc-

saml-core-1.1.pdf

12. Geuer-Pollmann, C. (2002) XML Pool Encryption. Proceedings of the Workshop on XML

Security. Fairfax, VA: ACM Press.

13. Harman, B., D.J. Flinn, K. Beznosov and S. Kawamoto (2003) Mastering Web Services

Security. Wiley.

14. IBM and Microsoft. Security in a Web Services World: A Proposed Architecture and

Roadmap - technical whitepaper 7 April 2002. See http://msdn.microsoft.com/ws-security/

303

15. XMLEnc. XML Encryption Syntax and Processing - W3C Recommendation 10 December

2002. See http://www.w3.org/TR/xmlenc-core/

16. WSDL. Web Services Description Language (WSDL) 1.1 - W3C Note 15 March 2001. See

http://www.w3.org/TR/wsdl

17. Robert McMillan. IDC: Web services to enable $4.3B hardware market by 2007. IDG

News Service (2003).See

http://www.computerworld.com/hardwaretopics/hardware/story/0,10801,81496,00.html

18. O'Neill, M., P. Hallam-Baker, S.M. Cann, M. Shema, E. Simon, P.A. Watters and A. White

(2003) Web Services Security. McGraw-Hill.

19. Papazoglou, M.P. and D. Georgakopoulo (2003) Service-Oriented Computing.

Communications of the ACM, Vol. 46, Nº 10, October 2003, pp. 25-28.

20. SOAP. SOAP Version 1.2 Part 0: Primer. See http://www.w3.org/TR/2003/REC-soap12-

part0-20030624/

21. WS-Security. Web Services Security (WS-Security) - Specification 5 April 2002. See

http://www-106.ibm.com/developerworks/webservices/library/ws-secure

22. XKMS. XML Key Management Specification (XKMS) - W3C Note 30 March 2001. See

http://www.w3.org/TR/xkms/

23. WS-Security Profile for XML-based Tokens - Specification 28 August 2002. See

http://www-106.ibm.com/developerworks/webservices/library/ws-sectoken.html

24. W3C Extensible Markup Language (XML) 1.1 - W3C Recommendation 04 February 2004

(2004). See http://www.w3.org/TR/xml11

304