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.
Thanks. Regards, aki 2013/2/28 John Li <[email protected]>: > 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 <[email protected]> wrote: > >> 2013/2/28 John Li <[email protected]>: >> > 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 (http://wso2.org/library/1027). >> > >> > Then I found the following post on the net where Dennis mentions this >> > problem to Aki ( >> > >> http://mail-archives.apache.org/mod_mbox/cxf-users/201103.mbox/%3C7b229db0-0865-47ec-8efe-2058b5808177@default%3E >> > ) >> > '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 >>
