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 15:30:24 GMT
Hi John,
there was some discussion on this topic at dev@cxf some years ago. But
there seems to be no jira ticket about it.
So if you can create one, that would be great.

Regards, aki

2013/2/28 John Li <>:
> Hi Aki,
> Since it's a known limitation, is there maybe already an CXF issue that we
> can follow to keep track of the progress? It's great to hear that you have
> a clear view on how to solve the issue. This issue is an important blocker
> since for example the european standards mandates a reliable profile where
> timestamps are required. This would mean that the cxf framework at the
> current moment cannot be used for those implementations.
> If there is anything you can see that I can help with the implementation,
> just let me know. I will do my best.
> Regards,
> John
> On Thu, Feb 28, 2013 at 11:28 AM, Aki Yoshida <> wrote:
>> 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