Securing Web Services - Fundamentals

Web Security : Introduction

Web Applications Security can broadly be categorized into following 2 types

1. Transport Level Security eg SSL
2. Message Level Security eg WS-Security

Transport Level Security (TLS) involves securing the transport channel. It may be deemed inadequate on account of following reason: TLS is essentially a point to point security mechanism. If there are proxies involved or message encounters multiple hops on its way to destination, there is no guarantee that the message security will not be compromised

Message Level Security (MLS) involves sending security tokens or authentication / authorization data as part of the message itself. Irrespective of any number of hops or proxies, security evaluation at the destination ensures much more reliable security.MLS is essentially a end to end security mechanism
It invariably adds performance overhead

 

Message Level Security for Web Services

Web Services - Security (WS-Security)

• WS-Security specification describes message level security standard as applicable for Web Services
• WS-Security specifies enhancing SOAP headers to include security information
• WS-Security provides a flexible mechanism for associating security tokens with SOAP messages
• Security tokens can be binary format certificates, XML-based SAML assertions, encrypted data
  

Web Services - Security

Web Services - Security specification, details the addition of xml-based security information to a Web service SOAP message. The following diagram clearly depicts how WS-Security headers and tokens, fit into a standard SOAP message

 

 

 

 

 

 

 

Security Tokens Supported by WS-Security are of the following types

• User Name token
• Binary Security tokens eg X.509, kerberos, tokens
• XML-based tokens eg SAML assertions
• Encrypted Data tokens
• Security token references
  

 

 

Common message-level Security Services provided are as follows

• Message Authentication as provided by certificates (binary security tokens)
• Message Confidentiality as provided by encryption mechanisms specified by XML Encryption Specification
• Message Integrity as provided by signatures specified by XML Signature Specification
• Message Security Credentials propagation
  

Note:
As per the flexibility of the WS-Security specification, the above 3 services can be combined in various ways to build security models with varying strengths and complexities

Skeleton SOAP Message using WS-Security

 

Cryptography and Keys

Asymmetric Keys

The most common scheme involves using a suitable cryptographic algorithm to generate public and private key pair.

1. The private key is provided by the source agent to the destination agent off-hand
2. The public key is used by the source agent, while encrypting the message
3. The private key is used by the destination agent while decrpyting the message

Symmteric Keys 

The most common scheme involves using a suitable cryptographic algorithm to generate a single key which is shared by both the source agent and the destination agent.. The same key is used for encrypting as well as decrypting the message, by source and destination agents, while sending and receiving the message.

Using symmetric keys though less secure has performance benefits. Some security schemes like the popular SSL protocol, use asymmetric keys for intial exchange of authentication information, once the channel is authenticated, subsequent exchange of pure data occurs using symmetric keys for performance reasons.

Digests and Digital Signatures

These are primarily security mechanisms to ensure message integrity, that is, to ensure that the message has not been tampered with, while it was in transit.

In the simplest case, the entire message or a part of the message, is run through a suitable encoding algorithm, to generate a unique hash-code, which is called a digest. This digest is sent along with the message to the destination agent. The destination agent reruns the received message through the encoding algorithm once again to generate the digest. The destination then verifies that the newly generated digest is same as the digest that ships along with the message.

This mechanism can very easily verify message integrity, but is not fool-proof, because, a sneaky message interceptor, could in theory, intercept the message, change it to its purpose and also change the digest, to be consistent with the modified message. To guard against this kind of tampering, additional to using message digests the message or part of its contents is also signed by the sender.

Steps involved in using digitals signature mechanism, are as follows

Source Agent:

• Calculates the digest based on some encoding algorithm, and attached the hashcode to the message
• Uses a private key to produce a digital signature, to sign the message with

Destination Agent:

• Receives message, checks the hashcode / digest value with message to be consistent with the message, using the same encoding algorithm, as used by the source agent
• Also uses a public key, issued by the source agent, to verify the signature.

Any undesirable interceptor, cannot, simulate the digital signature, since it does not have access to the source agent's private key. Thus, message integrity is assured.

Certificates

A certificate primarily contains the following:

1. Identification details of the certificate owner
2. public key as issued by the owner, for use by message receivers

Signed Certificates

Certificate issuing authority further, signs the certificate, using its own private key. This signature can be verified by the receiver, using the public key issued in the certificate. The certificate issuing authority may be  a trusted intermediary and not necessarily the message source agent.