Saturday, February 25, 2012

Timestamp in WS-Security to mitigate replay attacks

How replay attacks can be harmful:
When sensitive information is exchanged or critical transactions are performed over the network, we need to secure the communication.

General requirements of secure message communication are authentication, integrity, confidentiality and non-repudiation.

One can achieve above requirements through transport level security or message level security mechanisms such as security tokens, signature and encryption. 

Even though you adopt above mechanisms alone, to secure a message, one can intercept a secured message on the wire and resend the message repeatedly to the same endpoint and cause damages - unless there is a mechanism to verify the validity/originality of the message.

For an example:
- user logs into online banking and performs a transaction.
- an attacker traces the messages exchanged during the process.
- attacker resends the sequence of messages involved with login step, to login and steal money from the bank account.

Timestamp in WS-Security:
Therefore, it is important to validate the freshness of a message before performing any operation that the message invokes. This validation can be performed either in the business logic or security processing layer of the platform in a generic manner.

If your soap message processing engine supports WS-Security to achieve message level security; Timestamp element defined there helps verifying the message validity in terms of time.

(WS-Security is a spec that defines a framework to enable security related information -as specified by mechanisms such as XML security, XML signature etc- be embedded in the SOAP message.)

Timestamp element allows the sender to express the creation and expiration times of the security semantics of the message - using which recipient can validate the freshness of the security semantics of the message to mitigate replay attacks.

Following is the schema of Timestamp element.


Few points to be noted are:
  • Time references must be in UTC time.
  • Time references are recommended to be in xsd:dateTime format, if in any other format is used, it should be specified in ValueType attribute.
  • Spec doesn't mention any mechanism for synchronizing the time between sender and recipient - but specifies that this should be addressed.
  • Timestamp element should be signed in order to prevent it being forged.
  • Another sub element that may present in Timestamp element is "wsu:received"  which can be included by an intermediary.
  • Only one global timestamp element can be present in one security header.
Following is an actual Timestamp element extracted from a secured message:


Above what we discussed is the theory part related to Timestamp as defined in the spec. Now lets see how it is being utilized and processed in an actual implementation - by referring to Rampart and WSS4J.
Rampart & WSS4J:
Rampart is the Axis2 module which introduces security processing handlers to inflow and out flow of the Axis2 SOAP processing engine. Rampart internally utilizes WSS4J which implements the support for WS-Security.

Following are the rampart configuration parameters which allows user to configure and control Timestamp handling in Rampart and WSS4J. (Applies to Rampart 1.6.2 or above)


  • timestampprecisioninmilliseconds : whether the precession of timestamp reference is in milliseconds. This is a configuration parameter passed to WSS4J, when creating WSSConfig.
  • timestampttl : Validity period of the message as decided by the sender of the message. This is used in Rampart level to calculate "expires" time reference. Default value is 300 seconds. 
  • timestampmaxskew : Specifies the maximum tolerance limit for the clock skew between sender and recipient. As specified by WS-Security spec, it should be taken into consideration that renders and recipients clocks may not be in synchronized and proper measures should be taken to avoid it. This is a rampart level config parameter and the default value is 300 seconds.
  • timestampstrict :  This instructs rampart whether to enable timestamp validation at WSS4J level or not. By default - this is set to false. i.e: Timestamp validation happens in PolicyBasedResultsValidator of Rampart.
How Timestamp is created:
RampartSender is the handler introduced by Rampart for security processing of the out flow of Axis2.

In the process of securing the outgoing message according to the defined security policy, BindingBuilder adds Timestamp element to the security header.

Following is how 'created' and 'expires' time references of Timestamp are derived:
  • created = current time
  • expires = created(in millis) + timestampttl*1000
How Timestamp is validated:
RampartReceiver is the handler introduced by Rampart for security processing of the inflow of Axis2.

In the process of validating the security of the incoming message, both WSSecurityEngine(in WSS4J) and PolicyBasedResultsValidator(in Rampart) validates Timestamp in the security header.

WSS4J only checks whether the 'expires' time reference is before the current time of the receiver, to validate timestamp.

Rampart - on the other hand verifies timestamp taking timestampmaxskew also into consideration and validates against both 'created' and 'expires' time references.

Timestamp is invalid if:
  • current time < [created - (timestampmaxskew*1000)]  (in millis)
  • current time > [created + (timestampmaxskew*1000)] (in millis)
Because of the consistent way timestamp is verified in Rampart level considering both created and expired, the validation at the WSS4J is disabled by default with timestampstrict set to false - which was introduced with the fix for the issue RAMPART-357.

Other ways to avoid replay attacks:
According to the above logic of validating Timestamp, it is considered valid during the time period:
from (created - timestampskew) to (expires + timestampskew)
- which means replay attacks made during that period is not detected if any other mechanism is not adopted to detect and avoid replay attacks.

Some other mechanisms to avoid replay attacks are:
1. Using session keys.
2. Using one time passwords.
3. Using nonce value.

  • Understanding WS-Security

Tuesday, February 14, 2012

Implementing SCIM with Charon - Part II

We had a look at an overview of WSO2 Charon in my previous post.

Today lets go through a brief introduction of the module : Charon-Deplyment, which is the reference implementation of SCIM service provider that is shipped with Charon.

This will illustrate how any concrete implementation of a SCIM service provider can make use of Charon-Core (the SCIM API) with Charon-Utils (optional). So being the second post on Charon, this will continue the top down approach of looking at it.

As we got to know from the introductory post on SCIM, the protocol defines a REST API for user identity provisioning operations.

Hence SCIM service provider needs to be a RESTful web application. In an earlier post, I have noted down the characteristic of REST - which is an architectural style of building networked applications.

There are several ways to implement a REST style based applications - such as Servlets and JAX-RS based frameworks.

In the reference implementation of Charon-SCIM servervice provider, we have selected the latter approach since JAX-RS hides underlying HTTP handling and binds the servlets nicely to individual methods in the Java classes using annotations.  Annotations can also dynamically extract information from HTTP requests and map application-generated exceptions to HTTP response codes.

Out of the JAX-RS implementations, Apache-Wink was selected since it looks promising to cater our requirements.

The Charon-Impl module creates an Apache-Wink based web application which can be deployed in an application server like Tomcat and which acts as a SCIM service provider.

Following is a deployment diagram of Charon-SCIM service provider (the web application provided by Charon-Impl module). It also gives a high level idea on how Charon-Core and Charon-Utils modules will be utilized.

As this diagram of the reference implementation illustrates, a SCIM service provider can be developed using any REST implementation and SCIM-defined resources can be exposed utilizing the API provided by Charon-Core.

On the other hand, SCIM Consumers can also be implemented using the client API of Charon-Core.

More posts to be followed...

REST - an architectural style

Here in this post, I would like to keep some short notes on REST be written down.

REST is an architectural style to build networked applications. 
World wide web is based on REST style has following key characteristics:

1. Resources identified through URL:

URLs are defined to access every resource, which provides a consistent way of naming things in the web. This leads to build up a global addressing space for resource discovery.

Eg: A thing will have a url as :

A collection of things will have a url as:

2. Uniform interface for resources:

Every resource is exposed through a uniform interface consisting of a universal set of verbs - GET, POST, PUT, DELETE. All the operations to manipulate the resource should be aligned with this interface.

This enables any component that understands a RESTful protocol (i.e HTTP), to communicate with the application and also avoids the need of having WSDL like service descriptions.

3. Multiple representations for resources:

Resource is a concept. It can have multiple representations - represented in multiple formats for different needs. These representations can vary from HTML like web pages to XML to JSON to many more.

4. Stateless Communication:

RESTful  server application doen't retain state - it is either turned into resource state or maintained in client.

This characteristic provides several advantages such as:
       - avoids server being coupled to specific client
       - load balancing becomes easier
       - more reliable to network failures
       - minimizes server footprint

- REST is first defined in PhD thesis of Roy Fielding

Sunday, February 12, 2012

Implementing SCIM with Charon - Part 1

You may need to refer to my previous blog post in order to get an overall idea on SCIM - Simple Cloud Identity Management..

This is about WSO2 Charon - one of the SCIM implementations which will be made available under Apache 2.0 license. Lets look at it in a top down approach.

Following diagram will give an overview on the module break down of Charon along with purpose of each module and  planned tasks of them.

Following is a brief introduction on each of the modules:
  • Charon-Core:
        This is the API that exposes an implementation of SCIM specification. It can be used by any SCIM service provider or client implementation to support SCIM operations/functionalities. In addition to that, it also allows room for extension points to be plugged in according to the particular server side/client side implementation, such as authentication handler, user storage, encoders/decoders etc.
  • Charon-Utils:
          This contains a set of default implementations of the extension points mentioned above. For an example - Basic Auth, OAuth handlers, LDAP based user storage etc. A particular implementation that uses charon-core as SCIM API, can use these default implementations as building blocks.
  • Charon-Deployment: (Note: this is renamed as Charon-Impl)
       A reference implementation of SCIM service provider will be shipped with this module. Currently it is a Apache Wink based webapp that can be deployed in any application server - such as Tomcat, and make the SCIM endpoints be exposed. This is based on the above two modules : charon-core and charon-utils, and illustrates how any SCIM implementation can utilize the API and supporting module provided by Charon.
  • Charon-Samples:
          This contains samples illustrating the SCIM use cases. Samples contains mainly the SCIM client side implementations which can be run against a SCIM server, and hence can also be referenced to get to know how the API provided by Charon can be used to implement SCIM client side.

Well.. this is a brief overview of what Charon is, how it is structured and what each module is supposed to do, supposed to be used for.

 More posts on Charon to be followed...

SCIM - To overcome identity provisioning nightmares...

Identity provisioning is a key aspect of any Identity Management Solution.

In simple terms, it is to create, maintain and delete user accounts and related identities in one or more systems or applications in response to business processes which are initiated either by humans directly or by automated tasks.

Today the enterprise solutions adopt products and services from multiple cloud providers in order to accomplish various business requirements. Hence it is no longer sufficient to maintain user identities only in corporate LDAP.

In most cases, SaaS providers also need dedicated user accounts created for the cloud service users, which raises the need of proper identity provisioning mechanisms to be in place.

Currently, different cloud vendors expose non-standard provisioning APIs which makes it a nightmare for the enterprises to develop and maintain proprietary connectors to integrate with multiple SaaS providers.
For an example, Google exposes Google Provisioning API for provisioning user accounts in Google Apps Domain.

When enterprise IT systems consist of distributed, heterogeneous components from multiple vendors and from both in house and from cloud, it is key to have an open standard that all agree upon, in order to achieve interoperability and simplicity while getting rid of multiple connectors to perform the same thing.

Simple Cloud Identity Management is an emerging open standard which defines a comprehensive REST API along with a platform neutral schema and a SAML binding to facilitate the user management operations across SaaS applications; placing specific emphasis on simplicity and interoperability as well.

SCIM specification is in its version 1 and the cloud directory working group is  working on submitting it to IETF. You can get subscribed to and get updated with the latest happenings w.r.t SCIM spec.

Following embedded presentation which was used in a webinar, illustrates how some of the common use cases encountered in an enterprise identity management solution are achieved with SCIM.

We also identify the key characteristics of SCIM which makes it preferable over the other existing provisioning standards. Highlights of the overall SCIM specification -which is currently consisted of three normative parts, is also included in the slides.