Knowlegde Through Fun Welcome To Mady's Site.

Web Services security has been the most talked about thing in the Web
Services arena for quite some time now. If there's one thing that has
slowed the widespread acceptance and implementation of Web Services,
it's their lack of security standards. There also seems to be a
cautious implementation schedule for many companies that are thinking
about moving to the .NET platform. Partly because of security concerns
I would imagine, and partly to give the technology time to grab hold.
Nevertheless, security is still a major concern that holds back most
of the Web Service implementations today.

In April 2002, IBM, Microsoft, and VeriSign published a new Web
Services security specification, WS-Security. The specification aims
to help enterprises build secure Web Services, and applications based
on them that are broadly interoperable. Eventually, this specification
would be submitted for consideration as a standard, and looking at the
amount of commitment that IBM, Microsoft, and VeriSign have invested
in it, it should soon go that way. This specification proposes a
standard set of SOAP extensions that can be used when building secure
Web Services to implement integrity and confidentiality.

1. QUALITY OF PROTECTION

When we talk about security in Web Services, there are three types of
potential threats that need to be considered and addressed:

· The SOAP message could be modified or read by hackers.
· A hacker could send messages to a service that, while well-formed,
lack appropriate security claims carry on the processing.

· Service theft. For example, a subscription based Web Service that
doesn't authenticate or is not well secured is open to service
leeching by unauthorized users. Not necessarily hackers per se, but
people who are taking advantage of a hole in the service to get the
service for free.

A message security model is defined to understand these threats.

2. MESSAGE SECURITY MODEL

The WS-Security specification specifies an abstract message security
model in terms of security tokens combined with digital signatures as
proof of possession of the security token referred to as a key.
Security tokens assert claims, and signatures provide a mechanism for
authenticating the sender's knowledge of the key. This signature can
also be used to bind with the claims in the security token. This
assumes that the token is trusted. It may be interesting to note that
we do not specify a particular method for authentication. The
specification only indicates that security tokens may be bound to
messages. This is where the power and extensibility of WS-Security
lies.

A claim can be either endorsed or unendorsed by a trusted authority. A
set of endorsed claims is usually represented as a signed security
token that is digitally signed or encrypted by the authority. An X.509
certificate, claiming the binding between one's identity and public
key, is an example of a signed security token.

An unendorsed claim, on the other hand, can be trusted if there is a
trust relationship between the sender and the receiver.

One special type of unendorsed claim is Proof-of-Possession. Such a
claim proves that the sender has a particular piece of knowledge that
is verifiable by appropriate actors.
For example, a username/password combination is a security token with
this type of claim. A Proof-of-Possession claim is sometimes combined
with other security.tokens to prove the claims of the sender.

3. MESSAGE PROTECTION

The primary security concerns in Web Services are confidentiality and
integrity. WS-Security provides a means to protect messages by
encrypting and/or digitally signing a body, a header, an attachment,
or any combination of thees. Message integrity is provided by using
XML Signature in conjunction with security tokens to ensure that
messages are transmitted without modifications. The integrity
mechanisms are designed to support multiple signatures, potentially by
multiple actors, and to be extensible to support additional signature
formats.

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

4. MISSING OR INAPPROPRIATE CLAIMS

The message receiver should reject a message with an invalid
signature, or missing or inappropriate claims, as if it is an
unauthorized (or malformed) message, as would be expected in a secure
environment. WS-Security provides a flexible way for the message
sender to claim the security properties by associating zero or more
security tokens with the message.