Gap Assessment of the Top Web Service Specifications

learningsnortSecurity

Nov 3, 2013 (3 years and 9 months ago)

100 views


1




Gap Assessment of the Top Web Service
Specifications


Managing the Security of Web Services











Cristina Fhied


Advisor: Dr. Xiaoping Jia


















DePaul University

SE 690


Research Seminar


June 2004






2

Gap Assessment of the Top Web Ser
vice Specifications

Managing the Security of Web Services




TABLE OF CONTENTS




Table of Contents.…………………………………………………………………………2

Introduction.……...……………………………………………………………………..3
-
4

Web Services Background….…………………………………………………………...5
-
6

Web Service Security E
nterprise Security Requirements……...………………….……6
-
7

Web Service Security Specification (WS
-
Security)……..…………………………….7
-
10

Security Assertions Markup Language (SAML)...………………………………...…10
-
13

XML Key Management Specification (XKMS)…………...………………………...13
-
15

Public

Key Infrastructure (PKI)………………..…………………………..……...…15
-
16

Upcoming WS
-
Security Specifications………………………………………………17
-
18

Gap Assessment Tables………………………………………………………………18
-
20

Drawbacks and Benefits of each specification………………….………………....…20
-
22

Survey Results………………
……………………………………………………..…23
-
28

Conclusion………………………………………………………………………..…..29
-
30

Potential Future Work………………………………………………………………....…30

Appendix A: Overall Model of WS
-
Security and Interoperability ……………….…..…31

Appendix B: Raw data of Survey Results………………………………
……….…...32
-
35

Bibliography……………………………………………………………………….…36
-
37





















3

Gap Assessment of the Top Web Service Specifications

Managing the Security of Web Services



INTRODUCTION

Problem Definition


In today’s growing business markets, many companie
s are thinking of expanding their
business through the use of web
-
services. But there is a fear of expanding their market
over the Internet due to the fear of security standards. Last year thousands of companies
lost customers due to hackings of private da
ta. Without security standards that are solid
and clear, many enterprises are restricting Web Services to manage projects [Rubenking,
2002].


To date, much of Web Security is built around encryption through SSL (Secure Socket
Layers). SSL is good enough fo
r hiding a credit card number but it is not enough to
protect supply
-
chain operations and other business
-
to
-
business transactions [Rubenking,
2002]. This problem has created the need for the development of new service security
standards. One of these secur
ity specifications is the Web Service Security Specification
(WS
-
Security) the newest specification available for security protection. But there is a
problem, how do you know which specification to pick with so many to choose from. It
becomes an overwhelmi
ng issue, especially if you are working on a project that has a set
timeframe for deliverable and do not have the time to research all those available
specifications. In this survey/research technical comparison document I give an outline of
what is curren
tly available, how these specifications compare to the actual enterprise
requirements, what does the actual market look like conducted by actual professionals
and charts/model that you can be guided by.


Statement of Objective:


In this research gap assess
ment paper, I explore WS
-
Security Specification in greater
detail as well other currently available web specifications through the use of articles
researched through the use of ACM and IEEE. I will also present the current state of the
enterprise security
market and the recent features added to secure these specifications by
conducting a survey, which I will provide to approximately 25 working IT professionals.
Then I will discuss the considerations involved in making a decision on whether to use
one specif
ication over another by including a gap assessment of how each specification
maps to the network and communication enterprise requirements for a secure web
service. I will also provide a summary exposing the weaknesses and strengths of each
available web s
ervice specification.


As an extension to my research, I will present an overall model demonstrating how WS
-
Security specification can be used in conjunction with existing web service specifications
mapping to the actual enterprise requirements to form mor
e stable security architecture
by meeting every enterprise security requirement.


4

The information provided is not meant to be an exhaustive review of available web
service security specifications or of their capabilities. Instead, it is meant to provide a
b
etter understanding of the variety of capabilities provided by WS
-
Security and the
relative strengths and weaknesses.


Summary of Research Plan and Objectives:


The goal of this research/survey project is to provide a guideline on helping an
information te
chnology professional, preferably an individual working in the networking
area, decide on choosing a web
-
service specification when developing a security
framework for the development of a software project or architecture. With the vast array
of web
-
servic
es specifications available, it is difficult to determine a single, “best”
strategy for securing web
-
service applications. Instead the following can make the
following general research recommendations:


1.

Research the four available web
-
service security spec
ification through the use of
IEEE resources.



WS
-
Security



PKI



SAML



XKMS

2.

Conduct an enterprise state survey of 8 questions exploring the gaps, challenges
and specification in today’s current web service job area.

3.

Research the Communication, Network, and Arc
hitectural Enterprise
requirements for building and structuring a secure Web services.

4.

Prepare 3 gap assessments tables explaining the mapping of Communication and
Network Enterprise security requirements against the available and new coming
specifications

that are available.



One table will be a gap assessment mapping between Communication
enterprise requirements and available security specifications.



Second table will be a gap assessment mapping between Network enterprise
requirements and available securit
y specifications.



Third table will be a comparison mapping of the actual architecture
requirements against the available security specifications.

5.

Summary of the benefits and weaknesses of each available researched security
specification and an overall UML
model demonstrating how WS
-
Security
specification can be used in conjunction with existing web service specifications
mapping to the actual enterprise requirements.


First, it is important to go over what is needed in having security on the use of Web
Serv
ices.





5

Web
-
Service Background


What are Web Services?

According to the Infravio Institute of Domain Expertise Series and IBM, a simple
definition for Web Services is; “software pieces that dynamically interact with one other
using Internet standards to c
reate an application in response to requests that conform to
agreed
-
upon formats” [Infravio, 2002].


But how does Web Services work? Well, to execute a web application, a customer
located anywhere in the world needs only to know the URL of the web site wh
ere the
application is running. Web services then come into play by not only executing through
the Internet but within the Internet. This new process is often described as “publish
-
discover
-
bind.” When a new web service is developed, it is first published
on the Internet
for any potential user. A user looking for the application discovers the Web Service in a
public registry, and a binding occurs between the user that is the client and the server.


How is this possible? In order to be published, a Web Servi
ce must be described. The
XML
-
based language for describing a Web Service is called Web Services Description
Language (WSDL). A Web Service is described in WSDL and published for discovery in
a registry that conforms to the standard for Universal Descript
ion and Discovery of
Information (UDDI). When a request is made that matches the description, a binding
occurs, and the application processes the request.


What language is used to transport the requested data? There are a number of options, but
all are ba
sed on XML. These include Simple Object Access Protocol (SOAP), ebXML,
and XML
-
RPC. At present, SOAP is the language used most commonly for data
transport [Connolly, 2001].


In summary of what Web Services are; is that sending SOAP messages to services
id
entified by URIs can access them by requesting actions, and receiving SOAP message
responses. The broad goal of securing Web Services breaks into the need of providing
facilities for securing integrity and confidentiality (I will later explain what these t
erms
mean) of the messages and for ensuring that the services acts only on requests in
messages that express the claims expressed by policies.


What are these claims? A web service can require that an incoming message prove a set
of claims (in example, na
me, key, permission, capability, etc.). If a message is sent
without a claim, the service may ignore or reject the message. The set of required claims
and related information is referred to as policy. A requester can send messages with proof
of the require
d claims by associating security tokens with the messages. But these
messages demand both a specification and a specific action and prove that their sender
has the claim to demand the action. When the requester does not have the required
claims, the reques
ter can try to obtain the necessary claim by contacting other web
services. These other web services, are referred to as security token services, may in turn
require their own set of claims [Santani, 2002].



6

This current web service is sufficient enough f
or specifications to provide higher
-
level
authentication, auditing, and trust mechanisms.


What are the Web Service Security Enterprise Requirements?


The up
-
to
-
date requirements are nicely summarized in the article:
http://builder.com/article.jthtml?id=u00320020610GXS01.htm


And offer the following defined formal requirements:


First of all the description of a web service should include a security policy, and the
architecture must

provide an interface for web services to communicate with their
infrastructure [Myerson, 2002].


There are four basic security requirements for web
-
based communications, they are:


Authentication

Authentication ensures that each entity involved in using

a Web Service is what actually
claims to be. Authentication involves accepting credentials from the entity and validating
them against an authority. Credentials are embedded in either the headers or body of the
SOAP message.


Authorization

Authorization
determines whether the service provider has granted access to the Web
Service to the requestor. Authorization confirms the service requestor’s credentials. It
determines if the service requester is entitled to perform the operation, which can range
from in
voking the Web Service to executing a part of its functionality. In addition to
authorizing what information users/applications have access to, there also need to be
authorization of which operations an application or user has access rights to perform
tho
se operations.


Data Protection, Confidentiality

Data Protection ensures that the Web Service request and response have not been
tampered with en route. It is worth mentioning that data protection does not guarantee the
message sender’s identity. Standard

SSL encryption using HTTPS allows point
-
to
-
point
data privacy between service requestors and service providers. In many cases, the service
provider may not be the destination for the message. A service provider may act as a
service requestor, sending pie
ces of information to multiple services. The XML
Encryption standard permits encryption of portions of the message allowing header and
other information to be hidden clear text while leaving the sensitive information to be left
encrypted to the destination
, allowing true end
-
to
-
end data privacy [Myerson, 2002].


Data Integrity

Data Integrity guarantees that the message sender is the same as the creator’s message. It
attributes assertions containing specific details about the user. Digital signatures can be
used to verify if a message has been tampered with. A service requestor can sign a

7

document with the sender’s private key and send it along with the information (payload)
of the message. The service provider can then verify the signature with the sender’s

public key to see if any portion of the document has been compromised. The system can
ensure data integrity when communicating with each other.


While XML Web Services uses the same transportation mechanisms as Web
-
based
traffic, a network requires additi
onal security other than the four basic security
requirements for web
-
based communications as stated above [Myerson, 2002]. These
additional requirements are:


Interoperability

Web Services enables integration with third parties, including suppliers, cust
omers and
partners, authentication and access rights must be tightly controlled. Unfortunately
because multiple parties are involved, it is difficult to standardize on one authentication
and access control schemes. Single sign on and credential mapping sol
utions can help
make these environments easier to administrate and easier for participants to use.


Scalability

Specialized hardware for performing cryptographic functions can be used to offset the
load of intensive functions such as signature verification

and decryption built into the
network, and can be located at each Web Service to share processing across multiple
services. An additional scaling issue is management and administration scalability. Being
able to effectively manage security policies across

combinations of service requestors and
Web Service interfaces should be considered early in the requirements phase.


Centralized Management

Diverse systems need to communicate with each other and it is difficult for each system
to maintain each other’s au
thentication rights and access control lists. One way to fix this
problem would be to give everyone the same credential, but this presents a problem and a
very serious one when one member becomes untrusted. New credentials must be sent to
all remaining tr
usted members. But again giving an individual credential to each service
is difficult to maintain when a user needs to be removed. Single sign
-
on solutions help
solve this problem by allowing credential mapping among many different systems.


Malicious Atta
ck

Protecting services and programs from hacker attacks. WSDL files and UDDI entries can
provide detailed information that enables a hacker to gain entry. The message format is in
XML format, which is self
-
describing and clearly shows the data elements.



Web Service Security Specification (WS
-
Security)


Now that we have an idea of what constitutes Web service security, I will define what
WS
-
Security is and how it is the foundation for building a stronger security over the
Internet. It defines the core fac
ilities for protecting:



8



Integrity



Confidentiality



Secure communication


IBM, Microsoft, and VeriSign published WS
-
Security in April 2002. Overall, this
specification aims to help enterprises build secure Web Services, and applications based
on them that a
re broadly interoperable. Enterprises can incorporate the new specification
as needed, into the different levels of their Web Service’s application.


Concepts

WS
-
Security supports, integrates, and unifies several popular security models,
mechanisms, and te
chnologies. It defines a standard set of SOAP extensions. These
message headers can be used to implement
integrity

and
confidentiality

in Web Service
applications. This specification also provides standard mechanisms for Web Services
applications to exchan
ge secure, signed messages (
Secure communication
) [Apshankar,
2002].


WS
-
Security provides for a generic mechanism to associate security tokens with
messages.
No specific type of security token is required by WS
-
Security
. It also
describes how to encode b
inary security tokens. Also includes extensibility mechanisms
that can be used to further describe the characteristics of the credentials that are included
in the message. Since WS
-
Security is designed to be extensible, it supports multiple
security token
formats.


WS
-
Security is a building block that is used in conjunction with other Web Services and
application
-
specific protocols to accommodate a wide variety of security models
[Novick, 2002]. It provides support for multiple mapping with other existing
technologies. This includes but is not limited to multiple security tokens (as said before),
multiple trust domains, multiple signature formats, and multiple encryption technologies.


This specification provides three main mechanisms: security token propa
gation, message
integrity, and message confidentiality. These mechanisms by themselves do not provide a
complete security solution. Instead, WS
-
Security is just a foundation on which secure
applications can be based. These mechanisms can be used independe
ntly (to pass a
security token) or in a tightly manner (signing and encrypting a message and providing a
security token hierarchy).


Obtaining WS
-
Security:


IBM released its Web Services Toolkit 3.1, in 2003. Systinet plans to release its WASP
(Web Applic
ation and Services Platform) Secure Identity product, which uses SAML as
one of its protocols. Microsoft also expects to release its own tool kits to support its WS
-
Security vendors are expected to follow [Chen, 2002].


To obtain the latest white paper des
cription, please visit URL:
http://www
-
106.com/developerworks/webservices/library/ws
-
secure/


9

How does it work?


WS
-
Security provides a means to protect messages by encrypting

and or digitally signing
a body, a header, an attachment, or any of these combinations. Message integrity is
provided by using XML Signature in conjunction with security tokens to ensure that
messages are transmitted without modifications. The integrity m
echanisms are designed
to support multiple signatures, potentially by multiple clients, and to extensible to support
additional signature formats.


The XML namespace URI that must be used by implementations of this specification is:

http://schema.xmlsoap.org/ws/2002/04/secext


The <Security> header block provides a mechanism for attaching security
-
related
information targeted at a specific receiver. The header block may be present many times
in a

SOAP message. As elements are added to the <Security> header block they should
be prepended to the existing elements. The <Security> header block represents the
signing and encryption steps the message sender took to create the message. When a sub
elemen
t refers to a key carried in another sub
-
element, the key carrying the security
should be prepended to the key using the sub element added, so that the key material
appears before the key using sub element [IBM, 2003].

The following shows the syntax of the

<Security> header:


<S: Envelope>


<S: Header>







<Security S: actor=”….” S: mustUnderstand = “…”>








</Security>






</S: Header>




</S: Envelope>


Another element used for sending authentication information is the Username
token. This
token gives a way of providing a username and optional password information [IBM,
2003].

The following shows the syntax of the <UsernameToken> tag:


<UsernameToken Id=”…”>


<Username>…</Username>


<Password Type=”…”>…</Password>

</UsernameToke
n>




Message confidentiality uses XML Encryption in conjunction with security tokens to
keep pieces of a SOAP message confidential. The encryption mechanisms are designed to
support additional encryption processes and operations by multiple clients.


10

What
are the Requirements?




Multiple security tokens for authentication



Multiple security tokens for authorization



Multiple trust domains



Multiple encryption technologies



End
-
to
-
end message
-
level security


Summary of WS
-
Security


WS Security specification is t
o describe a single
-
message security language that provides
for message security that may assume an established session, security context and/or
policy agreement.


Also defines standards for:



Quality of protection, including message security model, Message

Protection, and
missing or inappropriate claims.



Security elements, which includes encoding formats, signatures, and encryption.


WS
-
Security is a building block that can be used in conjunction with other Web Services
extensions and higher
-
level applicati
on
-
specific protocols to accommodate a wide variety
of security models and encryption technologies.



Example of other Security Specifications


SAML


The Security Assertions Markup Language (SAML) is an XML
-
based framework for
Web Services that allows the
exchange of
authentication

and
authorization
information
among business
-
to
-
business transactions. SAML is the first industry standard for
enabling secure e
-
commerce transactions through the eXtensible Markup Language.


SAML is an emerging security specific
ation for web services from the Organization for
the Advancement of Structured Information Standards (OASIS), to stop the days of
multiple sign
-
ons for companies and their business partners [Rosencrane, 2002].


SAML is a vendor neutral, XML
-
based framewor
k for exchanging security
-
related
information, called “assertions” between business partners over the Internet [Rapoza,
2002].







11

Concept


SAML is designed to deliver much
-
needed interoperability between compliant Web
access management and security produ
cts. In other words, users should be able to sign
on at one Web Site and have their security credentials transferred automatically to partner
sites, enabling them to authenticate multiple systems through web sites maintained by
associated business partner
s.


SAML allows companies to securely exchange authentication, authorization, and profile
information between customers or partners regardless of the security systems or e
-
commerce platforms that they have in place today. SAML promotes the interoperabilit
y
between disparate security systems, providing the framework for secure e
-
business
transactions across company boundaries.


SAML does not address privacy policies. Rather the partner sites are responsible for
developing mutual requirements for user authen
tication and data protection. The SAML
specification itself does not define any new technology or approaches for authentication.
Instead, it establishes assertion and protocol schemas for the structure of the documents
that transport security. By defining

how identity and access information is exchanged,
SAML becomes the common language through which organizations can communicate
without modifying their own internal security architectures [SAML, 2003].


Obtaining SAML:


The new SAML 1.0 specification is ba
sed on the merger of two formerly competing
security efforts S2ML and AuthML. The SAML 1.0 specification set was released in
February 2002, and the specification submission was provided to the Organization for the
Advancement of Structured Information Stan
dard (OASIS),
http://www.oasis
-
open.org/

in March 2002 for standardization by the OASIS Security Services Technical Committee.

The related Java technology API standard for SAML is currently in review at the Java
Community Process (JCP) program
http://www.jcp.org

as a Java Specification Request

JSR
-
155.


How does it work?


SAML is designed to work with HTTP, Simple Mail Transfer Protocol, file transfer
protocol and several XML fr
ameworks, including SOAP and eb
-
XML. SAML gives
guidelines on assertions to request and response messages in order to provide
authentication and authorization. SAML also shows how single sign
-
on can be achieved
when several web
-
services are interacting; th
is is achieved by adding XML assertions.


The main components of SAML are:




Assertions: SAML three different kinds of assertions. Authentication assertions
require that user prove his identity. Attribute assertions contain specific details

12

about the user.
The authorization decision assertion identifies what the user can
do.



Request/response protocol: this defines the way that SAML requests and receives
assertions



Bindings: This details exactly how SAML requests should map into transport
protocols such as so
ap message exchanges over HTTP.



Profiles: These
dictate
how SAML assertions can be embedded or transported
between communicating systems.


SAML makes assertions about credentials; it does not actually authenticate or
authorize users. An authentication serv
er does this in addition with the Directory
Access Protocol directory. SAML does link back to the actual authentication and
makes its assertions based on the results of that event.


The SAML standard is designed only for the exchange of secure sign
-
on inf
ormation
between a user and multiple issuing parties; it allows issuing parties to use their own
chosen methods of authentication for example, PKI, or password [Byous, 2004].


The following is a sample SAML
-
compliant request sent from a relying party
reque
sting password authentication by the issuing party [Byous, 2004]:


<samlp: Request…>


<samlp: AttributeQuery>





<saml: Subject>



<saml: NameIdentifier SecurityDomain=”sun.com” Name=”rimap”/>


</saml: Subject>



<saml: AttributeDesignator



AttributeName
=”Employee_ID”




AttributeNamespace=”sun.com”>


</saml: AttributeDesignator>


</samlp: AttributeQuery>

</sampl: Request>





Microsoft Incorporated to this point does not support SAML, but is considering
supporting it in its .Net Server operating system.


Summary of SAML


In a quick summary SAML defines XML/SOAP


based protocol interactions that
support real
-
time authentication and authorization across Web Services environments.
The standard defines requests and response messages that security domains use

to
exchange authentication, attribute and authorization information in the form of trust
for secure Web services, allowing Web services to register and manage cryptographic
keys used for digital signatures and encryption.


13

When combined with WS
-
security,
XKMS makes it easier than ever for developers to
deploy enterprises applications in the form of secure Web services available to
business partners beyond the firewall and assertion messages about users and
resources [Rapoza, 2002].


So basically a user lo
gs on to their home domain through authentication techniques
such as passwords, and this authentication is communicated to a federated destination
site through a SAML authentication assertion.


XML Key Management Specification (XKMS)


XKMS is an open speci
fication. XKMS has been published by the W3C as a
technical note. XKMS provides a standard XML
-
based messaging protocol by which
developers can outsource the processing of key management to dedicated services.
VeriSign, Microsoft and Web Methods are used

as an open standard to simplify the
securing of xml
-
based Internet transactions using Public Key Infrastructure and
digital certificates developed XKMS.


With XKMS, developers can integrate authentication, digital signature, and
encryption services, such

as certificate processing and revocation status checking,
into applications in just a few hours [Trustcenter, 2003].


How does it Work?


XKMS is an XML version of PKI handling. This specification gives guidelines on
how to integrate keys, certificates wi
th applications. XKMS uses SOAP over an
HTTP based network. XKMS server components are mostly implemented by
providers of public key infrastructure (PKI) providers, such as VeriSign. XKMS
defines a Web services interface to a public key infrastructure. Th
is makes it easy for
applications to interface with key
-
related services, like registration and revocation,
and location and validation. XKMS is a foundational specification for secure Web
services.


All XKMS protocol elements are defined using XML schema.

Elements in schema
definitions are in the XML schema namespace [VeriSign, 2003]:


xmlns=
http://www.w3.org/2000/10/XMLSchema


References to XML Key Management Specification schema defined using the pref
ix
“xkms” are in the namespace:


xmlns:xkms=
http://www.xkms.org/schema/xkms
-
2001
-
01
-
20


This namespace is also used for unqualified elements in message protocol examples.



14

The XKMS schema specifi
cation uses the elements defined in the XML Signature
namespace. The XML Signature namespace is represented by the prefix ds and is
declared as:

xmlns:ds=
http://www.w3.org/2000/09/xmldsig#


The RetrievalM
ethod element is used to convey information available from a remote
location. The XML Signature Specification defines the <ds:RetrievalMethod> as
follows [W3Org, 2003]:


<element name=”RetrievalMethod”>


<complexType>



<sequence>




<element ref=”ds:Tran
sforms” minOccurs=”0”/>



</sequence>



<attribute name=”URI” type=”uriReference”/>



<attribute name=”Type” type=”uriReference’ use=”optional”/>


</complexType>

</element>


An XKMS service supports the following operations:





Register: register key pairs
for escrow services. Either the client or the
registration service may perform generations of the public key pair. Once keys
are registered, the XKMS service manages the revocation and recovery of
register keys, whether client
-
or
-
server
-
generated. Addition
al functions are
reissue, revoke, and recover.



Locate: retrieves a public key register with an XKMS
-
compliant service. The
public key can in turn be used to encrypt a document or verify a signature.



Validate: ensures that public key registered with an XKMS

service is valid,
and has not expired or been revoked. The validation service can also be used
to check attributes against a public key.




Obtaining XKMS:



Version 2.0 is available since April 18, 2003



VeriSign and Entrust have white papers
on XKMS.



VeriSign has developed an XKMS Java SDK, which can be used for doing
interoperability testing.



The downloadable integration kit can be obtained for free at:
http://
www.xmltrustcenter.org/developer/verisign/tsik/download.htm
., This kit
includes a client API that performs XKMS services.



The URL or VeriSign’s XKMS Interoperability Service is: http://interop
-
xkms.verisign.com/xkms/Acceptor.nano


Summary of XKMS


XKMS pr
ovides many benefits. The most important benefits of XKMS are:


15



Easy to user: The XKMS specification allows developers to rapidly
implement trust features, incorporation cryptographic support for XML digital
signatures and XML encryption using standard XML
toolkits.



Open: The common XML vocabulary used to describe
authentication
,
authorization
, and profile information in XML documents makes XKMS
services completely platform, vendor, and transport
-
protocol
-
neutral.



Ideal for mobile devices: XKMS allows mobile

devices to access full
-
feature
PKI through client device interfaces.



Quick to Deploy: XKMS removes the need to delay PKI deployment; it
moves the complexity of PKI to server side components.



Future proof: XKMS supports new PKI developments since the impac
t of
future PKI developments is restricted to server side components.



Public Key Infrastructure (PKI)


According to the company ArticSoft PKI integrates certificate authorities and digital
certificates into total, enterprise
-
wide network security archite
cture. PKI encompasses
the issuance of digital certificates to individual users and servers; end
-
user enrollment
software; integration with corporate certificate directories; tools for managing,
renewing, and revoking certificates; and related services and

support.


Obtaining PKI:


VerisSign PKI managed service provides maximum flexibility, performance, and
scalability with the highest availability and security.

VeriSign Managed PKI is a cost
-
effective system for issuing digital credentials
throughout an ap
plication.


The following is the official VeriSign URL in obtaining the toolkit for PKI:

http://www.verisign.com/products/onsite/index.html


How does it work?


PKI integrates digital certificates and certificate authorities into enterprise
-
wide
network sec
urity architecture. It encompasses the issuance of digital certificates to
individual users and servers; end
-
user enrollment software; integration with corporate
certificate directories, and revoking certificates; and related services and support.


PKI pro
tects information in several ways:



Authenticate

identity: Allow individual users, organizations, and web site
operators to confidently validate the identity of each party in an Internet
transaction.



Verify
Integrity
: Ensures that the message or document th
e certificate sign
has not been changed or corrupted in transit online.


16



Ensure
Privacy
: Protect information from interception during internet
transmission.



Authorize

Access: Replace easily guessed and frequently lost user IDs and
passwords to streamline i
ntranet login security and reduce the MIS overhead.



Authorize
transactions
:
Can control access privileges for specified online
transactions.



Support for

Nonrepudiation:
Validate the user’s identities, making it nearly
impossible to later repudiate a digita
lly signed transaction such as a purchase
made on a web site.




The following [Vordel, 2003] is a PKI Signature Example:



<?xml version="1.0" ?>

<Signature Id="Vordel"

xmlns="http://www.w3.org/2000/CR
-
xml
-
c14n
-
20001026">

<SignedInfo>

<Canonicalizat
ionMethod Algorithm="None" />

<SignatureMethod

Algorithm="http://www.w3.org/2000/09/xmldsig#rsa
-
sha1"/>

<Reference

URI="http://www.w3.org/TR/2000/CR
-
xml
-
c14n
-
20001026">

<Transforms>

<Transform

Algorithm="http://www.w3.org/2000/CR
-
xml
-
c14n
-
20001026" />

</Tr
ansforms>


Summary of PKI:


PKI lets an enterprise take advantage of the speed and immediacy of the Internet
while protecting business
-
critical information from tampering and unauthorized
access [VeriSign, 2003].


In summary PKI gives the capability of [Ve
riSign, 2003]:



PKI offers users controlled access to an intranet for all information and
applications.



PKI allows secure extranets and Virtual Private Networks that give select
partners easy access to business
-
critical information stored on an internal
net
work to be created.



PKI provides a protected environment for safe information exchange at every
stage of a process.



PKI allows customers the confidence to purchase goods and services on the
web.







17

Six New Upcoming WS
-
Security Specifications


Microsoft

Corp. and IBM Corp., along with BEA Systems Inc., RSA Security Inc.,
SAP AG and VeriSign Inc., are announcing the publication of a new set of advanced
Web services specifications to help businesses share information securely between
applications and organ
izations in a standard way.


Using accepted standards and specifications around SOAP, security, transactions and
discovery, the new specifications represent the future in giving a new model of
advanced web services capabilities that integrate with currentl
y available
technologies with the changing requirements of upcoming applications.


When used with the specification WS
-
Security these new specifications provide a
framework that is extensible and flexible maximizing existing investments in a Web
services i
nfrastructure.


These new specifications fall into two groups. The first group addresses key technical
worries in the area of security.


The first groups comprises of:



WS
-
Trust


describes the framework for managing, establishing and assessing
trust relat
ionships to enable Web services to securely interoperate



WS
-
Secure Conversation


describes a framework to establish a secure
context for parties that want to exchange multiple messages.



WS
-
Security Policy


describes general security policies that can be
associated with a service.


The second group focuses on the implementation of business policies in a Web
service environment:



WS
-
Policy


outlines a way for senders and receivers of Web services to
communicate their requirements and capabilities, which all
ow them to search
for and discover the information they need to access the service.



WS
-
Authorization


provides a standard mechanism for authorizing the
requirement and capability statements to the Web service



WS
-
Policy Assertions


describes general polic
ies that can be affiliated with a
service.


Used together with WS
-
Security specification these specifications complete all the
enterprise security requirements for building a secure web
-
service application.







18

Below is a model depicting the foun
dation of establishing a secure web services
through the use of WS
-
Security and the basis for other security specifications to layer
it and build a more stable and solid architectural security framework.















Summary of the upcoming web WS
-
Securit
y specifications


These specifications together will bring a solid foundation to the future of the security
architecture of web services. These specifications are WS
-
Policy, WS
-
Trust, WS
-
Privacy, WS
-
Secure Conversation, WS
-
Federation, and WS
-
Authorization.



Results


With the vast array of web
-
service specifications available, it is difficult to determine a
single, “best” strategy for securing web
-
service applications. Instead, the following
general recommendations can be made. In this result section I have

included the
following:




Benefits and drawbacks on using each web service security specification.



Discussion of how each web service specification can be used in conjunction with
WS
-
Security.



Gap Assessment of Enterprise Network Requirements against the c
urrent
available web service security specifications that I have researched.



Gap Assessment of Enterprise Communication Requirements against the current
available web service security specifications that I have researched.



Gap Assessment of Enterprise Arch
itectural Requirements against the current
available web service security specifications that I have researched.



An UML state diagram showing the interoperability of WS
-
Security and the
leading available web security specifications.



Survey questions and re
sults of the current Enterprise Web
-
Services. Also,
recommendations of what security specification to use based on the results of the
survey.


WS
-
Secure
Conversation

WS
-
Authorization

WS
-
Policy

WS
-
Policy Assertions

WS
-
Security Policy

WS
-
Trust

WS
-
Secure Conversation

SOAP Foundation





19

Gap Assessment Tables


Network Enterprise Security Requirements Mapping Comparison

The following chart provides a

summary comparison of the key web
-
based enterprise
requirements against the available security specifications researched.


Requirement

WS
-
Security

SAML

XKMS

PKI

Authentication Support

X

X

X

X

Authorization Support


X

X


Data
Protection/Confidentiality
Support

X



X

Data Integrity Support

X



X


Communication Enterprise Security Requirement Mapping Comparison

The following table provides a summary comparison of the key network enterprise
requirements against the available security specifications resear
ched.


Requirement

WS
-
Security

SAML

XKMS

PKI

Interoperability
Support

X

X



Scalability
Support

X




Centralized
Management
Support


X


X

Malicious
Attack Support



X



Architectural Enterprise Security Requirement Mapping Comparison

The following tab
le provides a summary comparison of the key architectural
requirements for a secure web
-
service.


Requirement

WS
-
Security

SAML

XKMS

PKI

Specification provides
guidelines for securing
private keys outside the
scope of architecture


X


X

X

X

The specificat
ion includes
key management
pertaining to Public Key
Encryption (PKE) and
Key Distribution Center
(KDC)



X

X

The security framework
document recommends a

X

X



20

baseline for trust models

The specification provides
an interface for web
-
services to directl
y
communicate with their
underlying infrastructure

X

X


X

The security specification
framework provides
recourse for web
-
services
to miligate the hazard
against security hazards



X

X

The architecture supports
common business
functions

X


X

X

The archit
ecture supports
reliable messaging and
routing

X

X

X

X

The web
-
services
architecture must support
unique messages IDs and
message sequencing


X

X


The specification
document must be
regularly referenced by
other specifications,
including but not limited
to W3C specifications


X


X





Drawbacks and Benefits of each Web Service Security Specification


WS
-
Security


Benefits:



WS
-
Security implements integrity and confidentiality in web services
applications.



WS
-
Security is a building block or better yet a bl
ueprint that can be used in
conjunction with other web
-
service security specifications to build a more stable,
solid security framework.



WS
-
Security integrates, unifies and supports many popular security models,
technologies and mechanisms.



WS
-
Security def
ines how signatures can be used in a web service application.



WS
-
Security provides for a generic mechanism to associate security tokens with
messages. WS
-
Security does not require any type of security tokens.


21



WS
-
Security not only provides support for mult
iple mappings with other existing
technologies, but also supports multiple security tokens and multiple encryption
technologies.



WS
-
Security is a solid open standard that is based on security models and this
means that this model will develop rapidly.


Dra
wbacks:



WS
-
Security specification does not discuss how proof
-
of
-
possession must be
implemented.



WS
-
Security does discuss how subject confirmation must be implemented.



WS
-
Security does not describe fixed security protocols.



Their needs to be significant ef
forts applied to ensure that security protocols that
are implemented using WS
-
Security are not exposed to a wide range of attacks.



WS
-
Security is not approved as a standard just of yet; this means that there are no
commercial web
-
services that use these sp
ecifications.


XKMS


Benefits:



XKMS Integrates Authentication, digital signatures and encryption.



XKMS does status checking in a matter of hours.



XKMS rapidly implements trust features, incorporating cryptographic support for
XML digital signatures.



XKMS m
oves the complexity associated with PKI integration to server side
components.



XKMS specification toolkit is completely platform, vendor, and transport
protocol independent.



XKMS protects developers and applications from becoming incompatible with
latest d
evelopment of PKI.



XKMS is developer friendly, and the syntax used eliminates the necessary plug
-
ins PKI requires.


Drawbacks:



XKMS has no implemented prototype depicting its available techniques.



XKMS has 3 associated standards with it:

1.

X
-
KISS (XML Key In
formation Service Specification)

2.

X
-
KRSS (XML Key Requirement Service Specification)

3.

Protocol Binding Specification

XKMS needs to have these three standards to be used at the same time, in
order to there be higher security. This means that XKMS is not a st
and
-
alone
application.






22

PKI


Benefits:



PKI integrates Authentication and digital signatures.



PKI allows individuals to confidentially validate the identity of each party in an
Internet transaction.



PKI ensures that the message or document the digital ce
rtificate signs has not
been changed in transit online



PKI protects information from interception during Internet transmission.



PKI validates a user identity making it impossible to later update a digitally
signed transaction, such as a purchase made over
the Internet.


Drawbacks:



Complications associated with the usage of proprietary PKI software toolkits.



Complex deployment associated with server side components.



Constraint of complexity in integrating authentication and digital signatures in
web service
applications.


SAML


Benefits:



SAML supports real
-
time authentication and authorization.



According to eWeeks Lab SAML is simple and straightforward to use.



SAML can interoperate with any kind of system.



SAML makes it possible message integrity and non
-
repu
diation of the sender.



SAML can handle single
-
sign
-
on capabilities. SAML authority is aware of past
authorizations and assertions.



SAML establishes assertions and protocol schemas for the structure of the
documents that transport security.



SAML links back

to the actual authentication and makes its assertions based on
the requests of that event.

Drawbacks:



Security of SAML conversation is not a stand
-
alone application. SAML depends
on the underlying trust model, which is typically PKI.



SAML does not address

privacy policies. Partner sites are responsible for
developing mutual requirements for user authentication and data protection.



SAML does not define any technology or approaches for authentication.



SAML only makes assertions about credentials; it does not

actually authenticate
or authorize users. An authentication server in conjunction with the Lightweight
Directory Access Protocol directory does this.



SAML lacks the backing of Microsoft Corporation.






23

Survey Results



Survey of Current Enterprise Techno
logies in Today’s Market in Security
Environment.


Objective of the survey was to explore areas of interest, concerns, and experiences to
those responsible for ensuring or working in areas of network/web service securities and
reflects the input of securit
y professionals across a spectrum of public and private
organizations.


Statistics and spectrum of the survey:

The final survey was passed out to 25 working Information Technology professional who
have knowledge in networking and Web Service security. The

number 25 is based on the
decision to only give the survey to networking and web service professionals; this area of
work is limited in size. The names of the companies have not been mentioned, as most
participants did not wish their organizations to be m
entioned in the research report.


A raw data summary of the responses to each question of the survey is included in the
appendix area of this paper.


About the survey:



The survey was of voluntary format.



The survey time for completion was approximately 10

minutes.



The survey was sent to approximately 30 people.



21 out 25 people submitted completed surveys over a time frame of 21 days.



The participants are current Illinois residents, working in companies residing in
Illinois.


Approach for conducting the su
rvey findings:



Pass out the survey to willing participants.



Request input on questions dealing with current web service problems,
specification used and not used and feed back on the actual enterprise
requirements to build a more secure web services.



Analy
ze the survey findings by building graphs using Excel.



Draw conclusions from the survey findings.



Make recommendations based on the survey results and compare to this to the
available web service security specifications.



Findings of the survey including
questions:


1.

Rank the following methods in terms of acquiring information security at your
organization.



24



Results are percentage based on average. The graph shows that the most
effective way in acquiring security in an organization is by conducting
vulnera
bility assessments and explaining the differences between security and
legal requirements. The least effective format was through the use of funding
from individual organizations.


0
10
20
30
40
50
60
70
80
Percent
Effectiveness in acquiring security in an organization
Most Effective
48
14
0
0
Efffective
19
14
5
71
Neutral
19
24
38
24
Somewhat Effective
10
33
19
5
Least Effective
5
14
38
0
Conduct
Vulnerability
Assessment
Scare with
Hacker
Stories
Fund
Security
from
Exp.
secuirty and
legal


2.

Have you acquired or do you plan to acquire t
he following:




Results are percentage based on average. This table shows that the highest
acquired item that Information Technology specialists use in their
development areas are Firewalls and Authentication Software/Services while
the least item acquired
is WS
-
Security, which can be due because of its recent
development.


Item

Acquire in
2003 or
earlier

Plan to
acquire in
2004

No plans to
acquire

Don’t Know

Authentication
Software/services

66%

5%

19%

10%

Firewalls

81%

10%

10%

0

PKI/Digital
Certification
s

24%

5%

14%

57%

WS
-
Security
Specification

10%

24%

33%

33%


25

Verisign
Specification

52%

10%

14%

24%

XKMS Specification

5%

0

24%

71%

SAML Specification

5%

0

24%

71%

Web Access
control/authorization

57%

19%

10%

14%

Vulnerability
Assessment

43%

14%

19%

24
%

Antivirus Products

81%

5%

14%

0


3.

Have you experienced any of these security breaches:



Results are percentage based on average. This table shows that most security
breach an individual has acquired is viruses and worms, while the lowest
experience is at
tacks related to insecure passwords.

Security Breach

Yes

No

Viruses or Worms

95%

5%

Attacks related to

Protocol Weaknesses

43%

57%

Attacks related to
insecure passwords

19%

81%

Attacks on bugs in Web
Servers

52%

48%


4.

Indicate your level of concern ab
out the following issues:



Results are percentage based on average. The graph shows that the highest
level of concern in an information technology is in malicious code infection,
while the lowest level of concern is physical security, which can be defined a
s
personal property.

0
20
40
60
80
Percent
Level of concern in the following issues
Most Ef f ect i ve
62
76
48
19
Ef f f ect i ve
19
19
33
24
Neut r al
14
0
10
14
Somewhat Ef f ect i ve
5
5
10
24
Least Ef f ect i ve
0
0
0
19
Syst em
Unavai l abi l i t y
Mal i ci ous
Code I nf ect i on
Loss of
Conf i dent i al i t
y/Pr i vacy
Physi cal
Secur i t y


26

5.

How important are the following to your organization:



Results are percentage based on average. This graph shows that the highest
level of importance to an organization is security and availability for Web s
ite
and e
-
commerce operations, while the lowest in importance is preventing
employees or outsiders from abusing access rights.


0
10
20
30
40
50
60
70
80
Percent
Level of Importance to an organization
Most Effective
71
38
43
33
29
Efffective
29
10
19
5
14
Neutral
0
10
38
43
48
Somewhat Effective
0
38
0
19
10
Least Effective
0
5
0
0
0
Avail. For web Site
and e-commerce
Securing remote
access for travelers
Strengthening the
network perimeter
Centralized manag.
Of control data
Prevention in abuse
of access rights


6.

Would you say the following are obstacles to security:



Results are percentage based on average. Th
is table shows that technical
challenges and complexity of products are the highest ranked in obstacles in
achieving web service security while the lowest was lack of competent
information security personnel.

Obstacle

Yes

No

Unclear Responsibilities

57%

4
3%

Technical
Challenges/complexity of
product

86%

14%

Lack of internal security
policies

57%

43%

Lack of competent
information security
personnel

33%

67%

Lack of employee
training/end
-
user
awareness

67%

33%




27

7.

How would you rank the following network i
ssue requirements based on security
framework importance:




Results are percentage based on average. This graph shows that the highest
networking issue requirements based on security framework is Interoperability
while the lowest rank is Centralized Managem
ent.


0
10
20
30
40
50
60
Percent
Ranks on the following network issue requirements
based on security framework importance
M ost Ef f ect i ve
3 8
3 3
5
3 3
Ef f f ect i ve
3 8
2 4
3 8
4 3
Neut ral
2 4
3 3
57
19
Somewhat Ef f ect i ve
0
10
0
5
Least Ef f ect i ve
0
0
0
0
I nt eroperabi l i t y
Scal abi l i t y
Cent ral i zed
M anagement
M al i ci ous
At t ack


8.

How would you rank the web
-
based communication security requirements based
on security framework importance:




Results are percentage based on average. This graph shows that the highest
communication security requirement
based on security framework is Data
Protection/Confidentiality while the lowest rank is between Authentication
and Authorization.



28

0
10
20
30
40
50
60
70
80
Percent
Ranks on the following communication security
requirements based on security framework importance
Most Effective
43
43
71
52
Efffective
29
19
29
48
Neutral
24
38
0
0
Somewhat Effective
5
0
0
0
Least Effective
0
0
0
0
Authentication
Authorization
Data
Protection/Confide
ntiality
Data Integrity


























29

Conclusion and Recommendations


Web Service Security is a major part of
today’s increasing technology, and with the
popularity of Internet business ever growing, it is sure to be demanded. As business
companies stretch their services into the web service world, it becomes increasingly
important for them to be able to recognize

and organize the different web security
specifications that are available for their use in their applications


This document can be served as a guideline in helping an application web services
individual choose the right specification or better yet specif
ications for his application.
This document introduces WS
-
Security, which is a building block that is used in
conjunction with other Web Service and application
-
specific protocols, to accommodate
a wide variety of security models and encryption technologie
s [see Appendix A].
Implementing WS
-
Security does not mean that an application cannot be attached or that
the security cannot be comprised.


The survey results, which were completed by Information technology professionals, can
be used as helping informati
on in viewing the current state of web service securities.
These results can be used in seeing the gaps and problems still facing many IT
professionals dealing with web services. While WS
-
Security can be used in conjunction
with many other web service spec
ifications, the following general recommendations can
be made:




When dealing with applications with strong authentication and authorization
requirements, WS
-
Security and SAML specifications can be considered.
Although many people answered as unaware of wha
t WS
-
Security this can be
due to the fact because it is very new specification.




When combined with WS
-
Security, XKMS makes it easier for developers to
implement enterprise applications in the form of secure web service
applications available to business p
artners beyond the firewall. XKMS also
when joined with WS
-
Security has a stronger use for digitally signing and
SAML assertions.




SAML when combined with WS
-
Security uses techniques such as XML
signatures and encryptions. SAML assertions can be carried

as security
tokens defined in WS
-
Security. SAML traffic could be secured by XKMS
-
based PKI.




When dealing with concerns of malicious attack and data protection XKMS
and SAML specifications can be considered.


In ranking the methods in terms of acquiring
information security in an organization, the
most effective way is by conducting vulnerability assessments and explaining the
differences between security and legal requirements. The least effective format was
through the use of funding from individual org
anizations.


30

The survey showed that the most acquired item that Information Technologist use in their
development areas are firewalls and Authentication Software/Services while the least
item acquired is WS
-
Security, which can be due to because of its recen
t development. I
hope that the findings present in this paper can change some minds.


The survey showed that the highest level of concern in an information technology is in
malicious code infection, while the lowest level of concern is physical security, w
hich
can be defined as personal property.


The survey showed that the highest level of importance to an organization is security and
availability for Web site and e
-
commerce operations, while the lowest in importance is
preventing employees or outsiders fr
om abusing access rights.


The survey showed that technical challenges and complexity of products are the highest
ranked in obstacles in achieving web service security while the lowest was lack of
competent information security personnel.


The survey showe
d that the highest communication security requirement based on
security framework is Data Protection/Confidentiality while the lowest rank is between
Authentication and Authorization.







Potential Future Work


Future potential work can be to research an
d analyze whether an implementation of WS
-
Security, PKI, SAML and XKMS on Web Services is enough to provide a system with
the needed securities. This application can be done using a java built interface consisting
of a password and username.
















31

Appendix
-
A


Overall Model of WS
-
Security and Interoperability



































WS
-
Security

Authentication

Authorization

Data Protection/

Confidentiality

Data Integrity

Interoperability

Scala
bility

Centralized
Management

Malicious Attack

Requirements

SAML

PKI

XKMS

SAML

XKMS

PKI

WS
-
Security

PKI

WS
-
Security

PKI

WS
-
Security

WS
-
Security

SAML

XKMS

SAML

WS
-
Policy
Assertion

WS
-
Secure
Conversation

WS
-
Security
Policy

WS
-
Trust

WS
-
Authorization


32

Appendix
-
B


Data Collected From the Surveys


Survey for research on “Gap Assessment of Security Web
Servi
ce Specifications”


Objective of the survey:


This Security Survey explores areas of interest to those responsible for ensuring
network/web service securities and reflects the input of security professionals on all
business levels across a spectrum of publ
ic and private organizations. Your input is
requested for the purpose of this research. The survey results will be shared with DePaul
University.


Name (optional):

Job Title:

Company Name (optional):



Please answer the following 8 questions as best as p
ossible. It takes approximately 10
minutes to complete the survey. Please return the completed survey to Cristina Fhied
(
cfhied@yahoo.com
).


1.

In your opinion, how would you rank the following methods in terms of
ef
fectiveness in acquiring information security at your organization on a scale
from 1
-
5 (1
-
least effective, 5
-
most effective)?


Method

1

2

3

4

5

Conduct
vulnerability
assessment to
demonstrate need for
security

1

2

4

4

10

Scare them with
hacker stories.

3

7

5

3

3

Argue that security
should be funded out
of individual business
units

8

4

8

1

0

Explain the
relationship between
security and
complying with legal
industry
requirements.

0

1

5

15

0


33

2.

Have you acquired or do you plan to acquire the following? (Pl
ace X if yes)


Item

Acquired in
2003 or
earlier

Plan to
acquire in
2004

No plans to
acquire

Don’t know

Authentication
softwares/services

14

1

4

2

Firewalls

17

2

2

0

PKI/Digital
Certifications

5

1

3

12

WS
-
Security
Specification

2

5

7

7

Verisign
Specifi
cation

11

2

3

5

XKMS
Specification

1

0

5

15

SAML Specification

1

0

5

15

Web access
control/authorization

12

4

2

3

Vulnerability
Assessment

9

3

4

5

Antivirus Products

17

1

3

0


3.

Have you experienced any of these security breaches (yes or no):

Security
Breach

Yes

No

Viruses or Worms

20

1

Attacks related to protocol
weaknesses

9

12

Attacks related to insecure
passwords

4

17

Attacks on bugs in Web
servers

11

10







4.

Indicate your level of concern about the following issues (1
-
no concern, 5
-
great
conc
ern):

Issue

1

2

3

4

5

System Unavailability
(e.g., bugs)

0

1

3

4

13

Malicious code infection
(e.g., viruses, worms)

0

1

0

4

16

Loss of
confidentiality/privacy
(e.g., misuse of data)

0

2

2

7

10

Physical Security (e.g.,
theft)

4

5

3

5

4


34

5.

How important ar
e the following to your organization (1
-
least, 5
-
greatest)?


Item

1

2

3

4

5

Security and
availability for
Web site and e
-
commerce
operations

0

0

0

6

15

Securing remote
access for
traveling
employees/remote
offices

1

8

2

2

8

Strengthening the
network
per
imeter to
prevent external
intrusions

0

0

8

4

9

Centralized
management of
control data

0

4

9

1

7

Preventing
employees or
outsiders from
abusing access
rights

0

2

10

3

6



6.

Would you say the following are obstacles to security (yes or no)?


Item

Yes

No

U
nclear responsibilities

12

9

Technical
challenges/complexity of
product


18

3

Lack of internal security
policies

12

9

Lack of competent
information security
personnel

7

14

Lack of employee
training/end
-
user
awareness

14

7




35

7.

How would you rank the foll
owing networking issue requirements based on
security framework importance (1
-
least, 5
-
greatest):


Issues

1

2

3

4

5

Interoperability

0

0

5

8

8

Scalability

0

2

7

5

7

Centralized
Management

0

0

12

8

1

Malicious
Attack

0

1

4

9

7


8.

How would you rank the w
eb
-
based communication security requirements based
on security framework importance (1
-
least, 5
-
greatest):


Issues

1

2

3

4

5

Authentication

0

1

5

6

9

Authorization

0

0

8

4

9

Data
Protection/Confidentiality

0

0

0

6

15

Data Integrity

0

0

0

10

11

































36

Bibliography


Web Services and Security:



Connolly PJ, Getting Serious about Web Security; InfoWorld, September 14,
2001


www.infoworld.com/a
rticles/tc/xml/01/09/17/010917tcsecurity.xml



www.webservicesarchitect.com



Web Services, Next Generation Application Architecture; Infravio,
February, 2002



Rubenking NJ, Securing Web Services; PC Magazin
e, October 1, 2002


www.pcmag.com/article=0,3048,a=30728,00.asp



A Joint White Paper from IBM Corporation and Microsoft corporation,
Security in a Web Services World; A proposed Archit
ecture and Roadmap;
April 7, 2002

http://msdn.microsoft.com/library/en
-

us/dnwssecur/html/securitywhitepaper.asp


Web Service Architecture:



Myerson J, We
b Services Architectures


How They Stack Up; Web Services
Architect, January 23, 2002


www.webservicesarchitect.com/content



Novick A, 15 Seconds: Complying with IT’s Security Requirements f
or Web
Applications; 15
-
Seconds, May 14, 2002


www.15seconds.com



Samtani G, Top 10 Web Service Security Requirements; Builder, June 10,
2002


http://builder.com.com/article.jhtml?id=u00320020610GXS01.htm



Gaudin S, Top 10 Enterprise Security Risks; IT Management, July 1, 2002


http://itmanagement.earthweb.com/secu



W3Org, 2003; Web Services Architect, 2002


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


WS
-
Security



Apshankar K, WS
-
Security


Security for Web Services; Web Services
Architect, 2002
-

www.webservicesarchitect.com



Chen A, Web Services Secure? eWeek, May 27, 2002
www.eweek.com/webservicessec



Cover Pages, Advanced Specifications for Web Services Security; December
18, 2002



Box D, et al. Web Services Policy Framework (WS
-
Policy); IBM, Version 1.1,
May 28, 2003
-

www.msdn.microsoft.com/webservices



Specification: Web Services Security (WS
-
Security), Version 1.0; IBM, Ap
ril
5, 2002


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



37

SAML:



Rosencrance L, SAML Secures Web Services; ComputerWorld, August
2002
www.computerworld.com/developmenttopics/development/webdev



OASIS, Security and Privacy Considerations for the OASIS Security
Assertion Markup (SAML) V1.1, September 2, 2003, 1
-
25



Rap
oza Jim, SAML Unlocks Door to Web Services; eWeek, December 9,
2002


http://www.eweek.com/SAML



SAML (Security Assertions Markup Language), NetworkWorldFusion, 2003


www.nwfusion.com/links/Encyclopedia/S/539.html



Byous J, Single Sign
-
on Simplicity with SAML; Sun, 2002


PKI:



Vordel l, ArticSoft, Introduction to Public Key Infrastructure; February 2,
2003, 1
-
6
www.articsoft.com/wp_pki_intro.html



Verisign, Understanding PKI; 2000, 1
-
2


http://verising.netscape.com/security/pki/understanding.h
tml


XKMS:



XML Trust Center, About XKMS; 2003, 1
-
2
www.xmltrustcenter.org/xkms/index.html



Verisign, Managed PKI, XML Trust Services
-
XKMS; November 16, 2003