cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aki Yoshida <>
Subject Re: WSRM in combination with WS-Security: timestamp problem
Date Thu, 28 Feb 2013 10:28:51 GMT
2013/2/28 John Li <>:
> Hi all,
> I have been working with the WSRM implementation of Apache CXF and now I'm
> combining it with WS-Security. After a struggle the createSequence call is
> successfully finished with WS-Security added but I am running into a
> problem with the retransmission. If no acknowledgement is received, the RMS
> is retransmitting the message with the same timestamp which is causing
> WS-Security to throw an error regarding a replay attack.
> After looking through the internet a bit I found the following post
> describing exactly the problem that I run into now and how it is solved in
> Axis2/Sandasha2/Rampart combination (
> Then I found the following post on the net where Dennis mentions this
> problem to Aki (
> )
> 'There are some deeper issues here around the way messages are persisted.
> Right now the message is just captured as sent on the wire. This works
> fine for plain messages, but once you add in WS-Security the handling
> needs to change so that the security information (timestamps, in
> particular) can be updated for each retransmission. That's going to
> require intercepting the message at a different point in the processing,
> and persisting in a different form.'
> In the documentation I found the following statement regarding the control
> that we have on the order of interceptors.
> 'The RetransmissionIntercepor will be added on the fly by the
> RMOutInterceptor so need not appear in your configuration file.'
> Can maybe someone help me define if this issue has been sovled or addressed
> in a CXF issue? Or is there some way to force the retransmission
> interceptor to go through the signing face again without creating multiple
> signature elements like what the Axis2 solution had?

Hi John,
this is a known limitation for the current WS-RM implementation. To
solve this, we need to split the current processing chain in two parts
so that we persist the plain message with the rm-props in the first
part and in the second part, we perform the rest of the processing
that includes an optional ws-sec processing and the final message
serialization and transmission. I was working on this some time ago
along with another change in the inbound side but somehow I was
interrupted with other stuff.

A related limitation that could be solved with this change is the
create-sequence's transmission error handling. Currently, you get an
exception when the create sequence message fails. For some
applications, it would be nice to have this message also queued and
retried so that the application does not need to handle this situation
using its own queuing.

I'll try to close some of the things that I have next week.

Regards, aki
> Any help is greatly appreciated. Many thanks in advance.
> With kind regards,
> John

View raw message