Monday, January 22, 2007

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

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.


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.

Wednesday, January 10, 2007

Yours truely published an article at

Article is about Implementing Crosscutting concerns using Spring 2.0 AOP

Monday, January 8, 2007

SOA Pros and Cons


  • involve business more closely and directly in defining business process
  • closer allignment of actual business requirements with software specs
  • processes / services more adaptive to changes in business requirements due to extra abstraction of business process composition layer. previously application logic was hardcoded to -business logic/requirements which kept on changing
  • re-use of business logic in the form of services at the macro / enterprise level
  • integration within enterprise, across enterprise is based on standards for service description, service implementation stack, service registration and lookup, service invocation


  • issues with services being stateless (at times business logic mandates service should be stateful)
  • issues with performance due to technology stacks for implementation and due to statelessness as well
  • standards for transactionality, coordination of services within an orchestrated process, are still evolving, currently a service can be assured of transactionality only within itself, there is no standard transactional behaviour support at the level of a process
  • service interaction is still popularly based on RPC-like request-reply paradigm, which is not as conducive to loose coupling as are event based interactions with an intermediary like a queue
  • not enough importance is given to the removal of hidden coupling introduced between services due to sharing of persistent data